diff -u: What's New in Kernel Development

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.