[2 Kool 2 Be 4-Gotten]

Two responses:

1. You can argue the theory now until forever but these questions are always complex enough that it all comes down to what works. When linux stared a micro-kernel was the “right” theoretical answer but the monolith worked. And it won.

2. So what? If Linux doesn’t like userland FS - so what - since it’s in user space, doesn’t that mean it can succeed with or without love from Linus? Or, alternatively, does it need certain kernel hooks to survive and indeed thrive?

[2 Kool 2 Be 4-Gotten]

Ouch, “If Linux doesn’t like userland FS” should have been “If Linus doesn’t like userland FS” - my fingers are too used to typing the “x” there LOL!

[ShadowAce]

I think it may be the implementation. If two groups are developing the same FS (say--btrfs, or something similar), and one group is developing it as kernel space, and the other as user space, guess which one gets accepted into the project?

OTOH, if the particular FS (XFS) is only user-space, then I don't see a problem.

[Verbosus]

Quote:
Or, alternatively, does it need certain kernel hooks to survive and indeed thrive?

I would think it is like the vfs and vfs_ops.h family of header files and accompanying calls.

You produce alternate functions to be called when the user
mounts/dismounts a file system as well as alternate functions for when any code uses typical file manipulation library calls (open(), stat(), read(), seek() or a dozen other typical calls).

You create kernel modules to load these into the kernel, and if any utility (anything from “ls” to “write()”, etc)performs an action within your file system, then your function gets the callout, and you can have your way with the data.

[NVDave]

Unless you’re working in as close to a “true” micro-kernel environment as possible, there are going to be issues (IO driver calls, scheduling, synchronization, memory copies/DMA shuffles) which the kernel will have to perform on behalf of the user-land FS.

In general, the only places I’ve seen user-land file systems succeed is where absolutely everything possible is stripped out of the kernel - ie, no half-way measures in making it a micro-kernel. Clocks/timers, interrupts, synchronization & IPC primitives, VM and *possibly* threading are all that is left in the kernel. Even terminal-IO has to be pushed out of the kernel (except for actual interrupt handling to an actual serial terminal).

The only commercial micro-kernel I’ve seen actually pull all this off was QNX’s Neutrino. Unlike most research or hobby micro-kernels, Neutrino delivered the goods and delivered them well. Maybe there are other microkernels that are ‘for real’ now, but I’ve been away from the industry on this topic for 10 years.

Microkernels look oh-so-sexy on paper.

Then when you actually start putting together a system based on them, you get to see whether they actually work or not. I’ve seen many micro-kernels utterly crash and burn in evaluation from a severe lack of IO performance from not thinking *really* hard about the overhead incurred by pushing the file system out to user space. The folks at QNX thought *really* hard about this and pulled it off - but there is still overhead involved that you wouldn’t have if all the IO stuff were still wrapped into the kernel, with no memory context changes necessary.