[haiku] Re: [GSsC] usermode Haiku or file system development
- From: Lucian Adrian Grijincu <lucian.grijincu@xxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Wed, 7 Apr 2010 17:11:46 +0300
On Wed, Apr 7, 2010 at 4:21 PM, PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
> 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.
The temporary bit is pretty fuzzy. The Linux guys are working on btrfs
now, which is meant to replace ext4 as file system-of-choice in Linux
once it gets stable. LKL already has support for btrfs at this point
through it's upstream implementation. Who knows when would someone
find the time to write a clean implementation for this. Or ext3, ext4
with read/write and journalization and more advanced features like
ACLs and extended attributes and whatnot. Or for for minixfs, xfs, afs
or jffs2 and it's in-development replacer logfs for flash devices.
Ok, not all of them are now useful to normal users. But normal users
might want read/write support and at least journalization (skip ACL,
and other advanced features) for ext2, ext3, ext4, ntfs, fat and in
the near future logfs and btrfs.
> 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 ?
Glad you asked.
Work on LKL started on an early Linux 2.6.22. I upgraded it to 2.6.29
in about two weeks while going to school, working on my graduation
project and while being a teaching assistant (~6-8 hours per week).
The upgrade brought ext4 and preliminary btrfs support without me
having to lift a finger in that direction. The upgrade had to work
past a very invasive internal architecture change inside the kernel
(they moved some architecture specific code in other places) and had
to work over many internal kernel API changes related to irqs,
internal VFS callback changes, block device driver changes, etc).
As most LKL code touches only stuff in a separate (virtual)
architecture, it's pretty self contained and only has to be changed
when the interfaces through which it communicates with generic Linux
code change.
Oh, and because applications built on top of LKL use only public
interfaces exposed by Linux, which being part of the ABI don't change,
we made NO changes to applications built on LKL but gained support for
ext4 and the rest.
For my master's project I plan on delivering a Windows file system
driver based on LKL. I really missed having proper ext3 write support
while I was a dual-booter, and I have friends that hate having
upgraded from ext2 to ext4 because they lost the ability to write on
those Linux partitions from Windows.
So LKL will be supported for some time from now on.
> Isn't it possible to
> find a cleaner solution that's easier to manage, like some FUSE support ?
By all means, the driver can be implemented in user space over FUSE,
but I got the idea that FUSE fs' are not desired from the idea page:
http://www.haiku-os.org/community/gsoc/2010/ideas
Did I interpret it wrong?
> As for the licencing :
> * 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.
I'll quote from src/add-ons/kernel/file_systems/ntfs/kernel_interface.c
* This program/include file is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as published
* by the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
You already carry GPLed code in the part of the system I meant to
insert the LKL file system driver. I don't know where to go with this
discussion now :)
> But then again, this is only my personal opinion, so I'll now stop annoying
> everyone with it :)
It's not annoying, thank you very much.
I'd like to ask you what you think about the other project I proposed:
the Haiku-kernel-library.
--
.
..: Lucian
Other related posts:
