Haiku file system drivers for any Linux supported file system
Personal Profile
- Lucian Adrian Grijincu
- Contact email: lucian.grijincu✆gmail.com, IRC:_gringo, dev.haiku-os.org: lucian
- Brief bio
I'm a master's student from Romania and have been a teaching assistant for the last three years at the Operating Systems course at my faculty. I've been employed/interned at a few companies:
- Kernel developer at IXIACOM - worked on networking optimizations on a custom embedded Linux kernel
- Software engineer at Freescale - added a new front end for the StarCore LLT compiler enabling it to re-optimize it's output and, for the first time, optimize hand-written assembly.
- Cross-platform C/C++ developer at AVIRA - optimized an internally used Linux TCP server, parallelized it (added multi-threaded abilities) and ported it to Windows.
- Software-engineer at Gameloft - wrote games for resource-limited mobile devices.
I am part of the Romanian translator teams for Ubuntu and GNOME and I'm a member of the Ubuntu Romania team (organizing Ubuntu events in Romania, solving Romanian-specific issues in Ubuntu, et al.)
I am a project manager for vmchecker, an open-source automated homework testing tool used at my faculty.
I've recently ended my job as a Linux kernel developer to be able to concentrate on my master's diploma project: finishing work on an already started open-source Windows file system driver built on top of the Linux kernel library (http://github.com/lkl/) and working on lkl-haiku-fsd :).
Project idea information
Haiku has great support for its own file system, but most others are only available read-only or simply not accessible. Providing reliable read-write support to file systems is not an easy task, and the complexity explodes when one takes into account journalization and the myriad of mount options supported by each file system (e.g. ACL, extended attributes).
Although interoperability with other systems is desired, faulty read-write support can lead to data corruption (mostly of the worst kind: silent data corruption). Because of this, file system code, especially write support, should be heavily reviewed by contributors with deep understanding of the file system internals before being merged. Small scale projects are unable to allocate resources for these kinds of tasks for a few simple file systems (e.g. ext2), let alone for complex ones or a great number of them.
The Linux kernel contains state of the art read-write implementations for a large number of file systems: ext2, ext3, ext4, resier, minix, fat, ntfs, et. al. with others coming along (namely btrfs – scheduled to become the default file system – and logfs – scheduled to become a default file system for flash devices). Bugs are routinely begin fixed, performance is improving, the internal Virtual File System (VFS) architecture sometimes changes and usually documentation lags behind. For small projects, keeping pace with such fast a development model is very difficult and is usually not considered a priority. This is why we now have very limited open-source support for some of these file systems in other operating systems: Windows, Haiku or *BSD.
Linux kernel library
Together with Octavian Purdilă, an university professor of mine, I've worked on a project called LKL - the Linux kernel library, which builds the Linux kernel as a portable library. LKL has been used so far in three kinds of applications/environments:
- LKLFTPD: an FTP daemon that reads/writes files from file system images
- LKLVFS: a file system driver for Windows
- a multi-router simulator making use of the networking stack (this is an ongoing diploma project)
I have worked on the core LKL and written most of the code for the FTP daemon (over 60%) and all of the file system driver for Windows (work in progress). Both make use of the Linux Virtual File System. 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 one gets into the mainline kernel, a git-merge will bring it in LKL. We also get bug fixes and performance improvements this way for free :)
The way we built LKL permits us to use it unchanged in a large domain of environments: inside other kernels (e.g. Windows), or inside user space applications as long as those environments provide a basic set of primitives:
- malloc/free-like memory management routines
- a synchronization mechanism (e.g. semaphores)
- thread creation/destruction
- a timer event generator
Project Goals
- Implement a Haiku environment for LKL
For LKL to run inside Haiku we need to implement the four required primitives mentioned earlier
There already are environments built for Windows kernel and POSIX or Win32 user space. Building one for Haiku should be easier having been through this three times and having examples.
- Implement a Linux block device driver mapped to a Haiku device.
To be able to access disk data we need to build a virtual device driver that translates Linux block device driver request to Haiku driver requests and Haiku responses to Linux block device driver responses. The virtual device driver will be invoked by the Linux VFS to read/write data from the real storage media.
I have already built such device drivers working with Windows kernel devices (LKLVFS) and working with file system images (LKLFTPD).
- Add lkl-haiku-fsd, a generic file system, in add-ons/kernel/file_systems
The first two goals just set up the LKL environment to be able to run and communicate with the disk driver. Understanding the internal logic of the file system is done inside LKL being as bug-free as on a regular Linux box: we share bugs and features alike. But to be able to call the LKL implementations we must route all file system calls from the Haiku kernel to functions exported by LKL's VFS and convert results back. This is a non-trivial task as I have seen while implementing the Windows file system driver.
- Work out the issues involving two sets of drivers for the same types of file systems.
Having two file system drivers for the same type of file system (e.g. lkl-haiku-fsd based ext2 driver and the native ext2 driver) may cause problems. We need to investigate how can we make them both work along. For example some users might desire MIT licensed drivers, some might desire native non-LKL drivers while other might want read-write support (through LKL drivers).
