There's a slow effort underway to allow virtually any part of the kernel to be extracted into its own shared library, thus enabling users to use any alternative subsystem they please. There's a long history of this, going back to the debate between micro-kernels and monolithic kernels. Even Linus Torvalds, the proponent of the monolithic kernel, believes it's better to abstract features out of the kernel, so long as it can be done without sacrificing speed, stability and other core requirements.

Most recently, Hajime Tazaki extracted the entire networking stack from the kernel and converted it into a shared library. This wasn't in itself part of a more generalized attempt to do such things, but while no one objected to the idea, there was considerable debate over the right way to architect the extraction, and this led to the thought that Hajime's idea could be extended to other subsystems beyond the networking stack.

Ultimately, Richard Weinberger suggested that the portion of Hajime's code that stubbed out the networking stack so it could be linked with a shared library could be added to the kernel's testing code and used to stub out any arbitrary portion of the kernel.

As it turned out, Antti Kantee had been working on a similar type of thing for NetBSD for the past eight years, but he cautioned that the maintainability issues could rapidly get out of hand if the design didn't aggressively address maintainability from the start. And this, he felt, would require organizing the deeper kernel infrastructure around the need to stub out portions of the kernel to be turned into dynamic libraries. But at that point, he said, the code would have only a very low maintenance cost.

Antti's recommendations were met with some suspicion. Richard felt that the maintainability issues might go deeper even than Antti cautioned, due to the tremendous speed of Linux development relative to that of NetBSD. In the end, Richard suggested—and Hajime agreed—that the best approach would be for Hajime to maintain the code, now dubbed libOS, as a separate git tree himself, to get an exact measurement of how well it could keep pace with the rest of kernel development.

It's not clear whether Hajime's code ever will get into the kernel. It seems a lot of people like the ability it offers, but there are unanswered questions about how well those abilities could be sustained over time. It may take a year or more to get a better sense of these things, and until the kernel folks know more, they'll be unlikely to accept this code into the kernel.

Beata Michalska has been working on generic filesystem event notification—a kernel interface that any filesystem could use to alert the system to various events, such as being remounted read-only. Beata described four basic categories of events: warnings, errors, information and thresholds. Thresholds would include things like the amount of free space dropping below a set minimum. The kernel could respond to filesystem events by triggering any desired response.

In response to Beata's patch, Heinrich Schuchardt suggested that her code should be expanded to cover a range of filesystem scenarios that it didn't yet—for example, distributed filesystems like Lustre, remote filesystems like Samba, and any FUSE-based filesystems also should be supported, he said. He also suggested that thumb drives and any other automounted filesystem also should trigger an event in Beata's code, and the same for filesystems mounted under virtual machines.

Various other folks also offered technical suggestions on how Beata could improve her initial patch, and Beata invited more implementation suggestions for some of the features Heinrich had requested.

One benefit everyone seemed to agree on is that a generic notification system would be highly preferable to each filesystem implementing its own notifications independently. So there was a lot of enthusiasm for Beata's work, although the exact technical details probably will continue to be hammered out for some time.