我将使用Linux NTFS驱动程序作为示例。
Linux内核NTFS驱动程序在内核中只有非常有限的写入支持，并且在5年后仍然被认为是实验性的。
同一个开发团队创建了ntfsmount用户空间驱动程序，它具有几乎完美的写入支持。
同样，由不同团队编写的NTFS-3G项目也有几乎完美的写支持。
为什么内核驱动器需要更长时间？开发难度更大吗？
说已经存在一个不错的用户空间应用程序并不是内核驱动程序不强制的原因。
注意：请勿将其迁移到superuser.com。从编程的角度来看，我想要一个编程重复的答案，而不是一个实际的用途答案。如果问题不适合SO，请告诉我为什么我可以这样编辑它。
答案 0 :(得分：5)
我不知道NTFS linux驱动程序开发的内部故事，但我可以想象一些会使用户空间开发比内核空间开发更快的事情：
答案 1 :(得分：4)
重要的是要注意，特别是对于Linux来说 experimental 也可能意味着“有人倾倒在这里的代码，当时看起来可以接受但可能没有被主动维护”。
我非常喜欢将文件系统保留在用户空间中，但我还应该指出我是一个很大的microkernel enthusiast。我认为将文件系统保留在用户空间是实际可取的，原因如下：
用户空间文件系统更易于维护
花点时间看看ext3cow file system这个PHD项目，该项目在很短的时间内获得了相当大的吸引力。它的作者毕业，然后转向职业生涯，没有多少时间在文件系统上工作。因为它不在树中，所以Linux在版本之间不断变化的内部需要任何想要在现代内核上使用它的人来获得并不是很多人拥有的深度知识。
如果它使用了FUSE API，它将更容易维护，并且将ext3转换为写入文件系统上的副本的实际工作将获得更多曝光。这也与内核代码有关，因为没有人足够勇敢（或足够无聊）触摸它。
用户空间文件系统更易于调试
在用户空间中，你有很棒的工具，比如Valgrind（以及像massif这样的朋友），它们是非常有用的工具，易于使用。与内核调试相关的学习曲线对于许多人来说往往太大了，只能跳入和编写代码。注意，我正在明确区分FUSE和微内核架构，如in this answer所述。一些基于微内核的系统极难调试，主要是由于运行服务（vfs，块设备，文件系统，ipc）之间的通信竞争。在这两种情况下，代码都更容易调试，因为内核的 out ，只要它不在内核中就不会引入奇怪的复杂性。
无论如何，我会在任何时候通过嘈杂的printk()调试来接受GDB和Valgrind，或者试图理解Linux中存在的相当神秘的内核调试钩子。我也很乐意使用我选择的任何调试（甚至是garbage collecting）malloc()实现。如果它适用于FUSE，我选择的C库也是如此。我不是在关注Linux的内核库，但我喜欢我的生物舒适。
用户空间文件系统更易于使用
对于弱势群体的用户来说，能够安装和维护他们想要使用的任何文件系统是一个很大的好处，但这实际上是最终游戏。如果您的文件系统不在内核中，它可以独立于内核前进，这意味着用户可以升级到您的发布周期。您可以想象，在Linux升级到下一个候选版本所需的时间内，您可以获得6个里程碑版本。这也允许发行版和OEM供应商在需要进行测试的情况下将您的FS放在野外，这比它是内核模块时更快。
Norman Ramsey already described与文件系统相关的可靠性因素，作为微内核架构中的服务。但是，可靠性意味着不需要转世服务，这种服务往往会隐藏（或推迟）错误和其他问题。我同意这一点，如果失败的根安装不会导致内核中止，那就很好了，但是对于支持单片FUSE的内核也是如此。
总之，编写文件系统非常困难，无需处理内核空间中的运行。我更愿意使用FUSE API，或者在基于微内核的操作系统中研究IPC / VFS服务实现，而不是将其作为内核模块编写。
答案 2 :(得分：2)
内核的代码必须符合比用户模式代码更高的安全性和安全性（即无错误）标准。
答案 3 :(得分：1)
您在用户空间可以获得更多好东西，因此开发软件更容易。如果文件系统停留在用户空间中，那么文件系统中的错误就会更难以打倒整个内核。
这个原则在Mach和Windows NT等项目中被采用极端，其中系统设计为microkernel，并且尽可能多的服务放在用户空间中。