Userspace file systems & MKs (Re: silent semantic changes with reiser4)

[Bill Huey (hui) <bhuey@lnxw.com>]

On Tue, Aug 31, 2004 at 12:38:14AM -0400, Jeff Garzik wrote:
> _My_ own definition of microkernel, which differs from traditional CS, 
> is where I would love to see Linux go:  move as much as humanly possible 
> to userspace, such that, the kernel only contains pagecache operations, 
> driver fast paths, and security checks.  Move slow paths, including ACPI 
> probing, PCI bus walking, driver init/reset paths, some of the ioctl 
> handling, to userspace.  Be willing to accept extra context switches as 
> a cost in all but the fast paths.

	http://www.dragonflybsd.org

DragonFly BSD, the only remotely functional open source BSD project on this
planet, has plans in place to push certain kernel components like their VFS
layer into userspace for easier debugging, testing and other things that go
with developing file systems easily. If they back it with something like C++
for doing constructor style type conversion on top of overloaded operators
to back VFS data structure translation, could easily import stuff like most
Linux file systems without major restructuring, say, if they had their
translation library written. In this case, userspace kernel systems have
some serious programming advantages over traditional kernels.

They're also pushing an async syscall model to support a non-1:1 threading
system for userspace unlike what Linux has done with futexes. It'll allow
for them to plug in various userspace schedulers at will for whatever
scheduling policy you want dynamically, even while the program is running.

This isn't mentioning their single system image clustering goals that have
abstracted various kernel systems like their VFS stuff to a messaging model
which should get them proccess migration as an intrinsic part of their OS
design. They've made a lot of progress over the last year and it's largely
because of Matt Dillon's ability to create a non-overly political group that
creates trust. He's a true leader, not some random loud mouth(s) unlike
other BSD efforts. It's much like the Linux community in this regard with
Linus.

bill