[haiku-development] lklhaikufs: progress report
- From: Lucian Adrian Grijincu <lucian.grijincu@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 12 Jul 2010 03:56:05 +0300
== What works? ==
LKL has been ported to run on Haiku’s kernel.
The Linux kernel can communicate with Haiku disk devices by means of a
simple virtual Linux disk driver that instead of sending requests to a
real disk calls upon Haiku’s kernel IO API (_kern_read/_kern_write).
The file system driver can detect file system images that are
recognized by the Linux kernel and automatically choose the proper
one. For example if ext3 and ext4 are built into LKL, and a ext4 file
system image is added to Haiku, the driver will first check ext3
(which will fail to mount the device) and then ext4 (which will
eventually succeed mounting it).
At the moment you can mount/unmount file systems, list files in the
root directory, and read and write a file's contents, stat, statfs,
access, open, read, write, close. Shortly this week I hope to have
directory traversal (not just the partition's root directory), mkdir,
rmdir, create, unlink.
== Where's the code? ==
The code has two components:
A) the Linux Kernel Library contains the Linux kernel, the port to the
Haiku kernel architecture, and Linux' virtual disk device.
The code can be downloaded from my github repository:
http://github.com/luciang/lkl-linux-2.6
You shouldn’t need to worry about it or how to build it, more about this bellow.
B) the second part is the file system driver for Haiku. As I agreed
with Niels from the beginning, it would be best for me to work on this
on a separate git repo, hoping to submit incremental patches whenever
the code is deemed stable enough to be included upstream. I’m
continuously rebasing this tree on the git.haiku-os.org tree, and I
rewrite the history as I progress => please tell me if you want to
clone the repo and start working on it so I’ll stop rebasing/history
rewriting.
The code can be downloaded from my github repository:
http://github.com/luciang/haiku
== How do I build it? ==
The driver code is located in the
src/add-ons/kernel/file_systems/lklhaikufs/ directory. Apart from
telling the driver the path to the LKL source tree, there is only one
thing you should add to your build/jam/UserBuildConfig:
AddFilesToHaikuImage system add-ons kernel file_systems : lklhaikufs ;
You build the Haiku image as normal (make an ISO, a QEMU or
VmWare/VirtualBox image, etc.).
In src/add-ons/kernel/file_systems/lklhaikufs/Jamfile the path to LKL
is still hardcoded:
LKL_LINUX_DIR = "/home/gringo/hack/lkl/linux-2.6" ;
You'll need to change this to where you cloned the repo.
== How do I test it? ==
Start your system and make sure to have a partition with a file system
that’s currently not supported by Haiku. If you’re using QEMU or
VmWare/VirtualBox disk images it does not matter if this partition is
found on the same disk image created by the build scripts or not, but
for testing it would be easier if it were on another disk drive as you
won’t have to repartition, reformat, recreate a testing directory
structure, etc.
Once you have booted the system you can check /var/log/syslog. As
Haiku starts up it load (among others) all file system add-ons,
initializes, then uninitializes and unloads them. You’ll see a few
messages that the Linux kernel writes as it boots up (done at
initialization), or shuts down (done at unitiliazation). They’re
pretty easy to spot, look for messages with “[lkl-console]” in them.
If the second partition is present at boot time, Haiku will ask each
file system driver if it can mount it. Drivers answer with a floating
point number whether they can mount it or not and state their priority
in mounting that file system (-1 means “I can’t mount this”, a
floating point number between 0 and 1 means “I can mount it, and the
value is my priority"). Native file systems usually return 0.8 for
file systems they recognize. My driver will return 0.6 to state that
it can mount it, but if anything better comes along (read: a native
file system driver), use that.
At this point Haiku knows what drivers it can use for each unmounted
partition. You can now explicitly mount this partition. There are two
solutions:
* GUI: use /boot/systems/apps/DriveSetup (should be in your PATH, so
“DriveSetup” from a terminal is enough), or go to
“Applications->DriveSetup”.
* shell:
** mkdir mnt; mount /dev/disk/ata/0/slave/0 mnt/
Haiku will use the file system driver that returned the
highest value for that partition.
** mkdir mnt; mount -t lklhaikufs /dev/disk/ata/0/slave/0 mnt/
Haiku will use the file system driver named after “-t”
(I know “lklhaikufs” is a bit long).
Now that you have mounted the file system you can start fiddling with
files on that partition.
== Any bugs? ==
1. As I said before, at the moment the driver can only access files in
the root of the file system. Should be fixed in the beginning of the
week.
2. ext4 doesn't fully work. You can mount an ext4 file system and list
files in it's root directory, but there are problems with stat() and
other operations. I've tracked this down for the past few days to LKL,
the error is not in my driver. I won't chase this anymore until I
upgrade LKL to a more recent upstream kernel. However ext3 works fine,
so you can work on that.
== Current implementation limitations ==
As of now, the ->private_node is the full path to a node. When I'll
get to unlink/rename I may need to reconsider this. I didn't start
with anything more complicated because:
* I want to write the right solution when I'll encounter the problem,
and not have anything more complicated than necessary
* it was easier :)
Another aspect is the addition of a new Haiku vfs exported function
(and maybe not very well named one) get_vnode_set_private_node -- does
what get_vnode does but instead of retrieving the private_node's
value, this one sets the node's private_node to a user specified
value.
--
.
..: Lucian
Other related posts:
