目前正在缓慢推进一项工作，允许将内核的几乎任何部分提取到其自身的共享库中，从而使用户能够使用他们喜欢的任何替代子系统。这方面有着悠久的历史，可以追溯到微内核和单内核之间的辩论。即使是单内核的支持者 Linus Torvalds 也认为，只要在不牺牲速度、稳定性和其他核心要求的情况下，最好从内核中抽象出功能。

最近，Hajime Tazaki 从内核中提取了整个网络堆栈，并将其转换为共享库。这本身并不是更广泛尝试这样做的一部分，但虽然没有人反对这个想法，但对于构建提取的正确方法存在相当大的争议，这导致人们认为 Hajime 的想法可以扩展到网络堆栈之外的其他子系统。

最终，Richard Weinberger 建议，可以将 Hajime 代码中用于桩化网络堆栈的部分添加到内核的测试代码中，以便可以将其与共享库链接，并用于桩化内核的任何任意部分。

事实证明，Antti Kantee 在过去的八年中一直在为 NetBSD 做类似的事情，但他警告说，如果设计从一开始就没有积极解决可维护性问题，那么可维护性问题可能会迅速失控。他认为，这将需要围绕桩化内核部分以将其转换为动态库的需求来组织更深层的内核基础设施。但他说，到那时，代码将只有非常低的可维护性成本。

Antti 的建议受到了一些怀疑。Richard 认为，由于 Linux 开发相对于 NetBSD 的惊人速度，可维护性问题甚至可能比 Antti 警告的还要深入。最后，Richard 建议——Hajime 也同意——最好的方法是让 Hajime 自己将代码（现在称为 libOS）维护为一个单独的 git 树，以准确衡量它在多大程度上可以跟上其余内核开发的步伐。

目前尚不清楚 Hajime 的代码是否最终会进入内核。似乎很多人喜欢它提供的功能，但关于这些功能在多大程度上可以长期维持存在一些未解答的问题。可能需要一年或更长时间才能更好地了解这些情况，在内核人员了解更多之前，他们不太可能将此代码接受到内核中。

Beata Michalska 一直在研究通用文件系统事件通知——一种内核接口，任何文件系统都可以使用该接口来提醒系统各种事件，例如被重新挂载为只读。Beata 描述了四种基本事件类别：警告、错误、信息和阈值。阈值将包括诸如可用空间量降至设定最小值以下之类的内容。内核可以通过触发任何期望的响应来响应文件系统事件。

为了回应 Beata 的补丁，Heinrich Schuchardt 建议应该扩展她的代码以涵盖一系列尚未涵盖的文件系统场景——例如，应该支持像 Lustre 这样的分布式文件系统、像 Samba 这样的远程文件系统以及任何基于 FUSE 的文件系统，他说。他还建议，U 盘和任何其他自动挂载的文件系统也应该在 Beata 的代码中触发一个事件，虚拟机下挂载的文件系统也应该如此。

其他一些人也为 Beata 如何改进她的初始补丁提供了技术建议，Beata 邀请为 Heinrich 要求的某些功能提供更多实施建议。

每个人似乎都同意的一个好处是，通用通知系统将比每个文件系统独立实现自己的通知要好得多。因此，人们对 Beata 的工作充满热情，尽管确切的技术细节可能还需要一段时间才能最终确定。