[haiku] Re: [GSsC] usermode Haiku or file system development
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Wed, 07 Apr 2010 16:10:40 +0200
On 2010-04-07 at 15:21:28 [+0200], PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
> Le Wed, 07 Apr 2010 15:07:15 +0200, Stephan Assmus <superstippi@xxxxxx> a
> écrit:
>
> > Hm, IMHO some arguemnts don't really apply to the situation at hand. LKL
> > would only be a dependency if you want to use any of the filesystems it
> > offers. The CPU architecture argument may be relevant to Google apps and
> > Wine, but it wouldn't apply to LKL.
> > After my initial doubts, I am starting to follow Lucian's argumentation.
> > Each one of us has a different area of interest in the Haiku world. With
> > some stuff, we are just glad it works and we don't care how. We just want
> > it to work reliably. For everyone of us who just wants a filesystem to
> > work
> > reliably, LKL may be a good solution. For the very few who care greatly
> > about providing a native implementation for a particular FS, with great
> > and
> > clean code, he can work on it and give LKL one less reason to be used.
> > After all, we do have a pretty annoying resource problem, where everyone
> > is
> > already completely overwhelmed by work on so many things.
>
> Sure, I think LKL is a way to get working fs support as a temporary
> solution and I'd definitely use it. But on the other hand, it's only meant
> to be temporary and I'm not sure I want a GSoC slot to be used for it.
Getting something coded is not our primary objective for participating in
GSoC. It's of course nice to get something useful out of it -- and that
would be totally the case for this project -- but the main goal is to
interest students in Haiku development and ideally win long-term
contributors.
> It
> would be a bit like getting a student working on the Qt port. Sure, this
> gets us KOffice running... but wouldn't we prefer a clean port of Abiword ?
Office suite oranges vs. word processor apples? Anyway as written above
that's beside the point. Any GSoC project the Haiku platform benefits from
is fine IMO.
> Here, we are talking about filesystems. I'm wondering how LKL handle
> updates to the linux kernel. It seems linux is changing quite a lot
> between versions, so would LKL be able to keep up with that, or does it
> need a lot of care to get it to compile against newer kernels ?
Already answered in Lucian's initial mail:
"Because file system
specific code is implemented inside the Linux kernel and because we
only make use of the public interface exposed by Linux (the kernel's
implementations of the POSIX file APIs) we remain file system
independent and can upgrade very easily: we just need to sync to newer
kernel versions and fix the eventual merge conflicts. This provides
instant support for newly developed file systems: once it's in the
mainline kernel, a git-merge will bring it in LKL. We also get bug
fixes and performance improvements this way for free :)"
> Isn't it
> possible to find a cleaner solution that's easier to manage, like some
> FUSE support ?
Userland solutions add significant overhead. Since our FUSE support is
provided as an interface to the userlandfs (which communication-wise sticks
very closely to the FS kernel interface), it is even less efficient than an
explicit FUSE port would be.
> As for the licencing :
I agree with Stephan that licensing is quite irrelevant in this case.
> * Either it's meant to be kept as spearate from haiku (optional package
> or whatever), in which case there is no licencing problems, but I'm not
> sure about it being part of GSoC
> * Or it's part of Haiku core, and then it should be MIT-licenced.
So we should e.g. remove the NTFS and ReiserFS code from the repository?
CU, Ingo
Other related posts:
