uclinux与设备驱动程序的必要性

通常，没有MMU的系统也没有MPU（内存保护单元），用户和内核模式之间也没有区别。在这种情况下，假设我们有一个没有MMU的系统，其中有一些硬件映射到CPU地址空间，如果所有硬件资源都可以从用户空间访问，那么在内核中有设备驱动程序真的有意义吗

---

内核代码比用户代码对内存的控制能力更强吗？

是的，在没有承载ucLinux的MMU的平台上，像使用普通的嵌入式Linux环境一样执行所有操作是有意义的。让用户应用程序和服务通过其正常接口（系统调用等）并让操作系统将这些内核请求路由到设备驱动程序、文件系统、网络堆栈等，这是一种更简洁的设计

尽管内核在这些情况下对硬件没有更多的控制，但实际的硬件应该只由内核中运行的系统软件来操作。不限制对硬件的访问将使系统重置和内存损坏等调试变得几乎不可能。这种做法也使您的设计更具可移植性

---

例外情况可能是用户模式调试二进制文件，这些二进制文件仅在内部用于平台启动和诊断。

谢谢Peter。在uclinux上，有没有一种方法可以限制userland应用程序访问（可能是意外地）硬件寄存器？@Mark我不这么认为。如果有，我将非常有兴趣了解如何。我参与的一个ucLinux项目有peek和poke实用程序，可以直接访问任何内存。但是，没有一个生产用户代码能够做到这一点。然而，WLAN驱动程序将访问它需要的寄存器，就像它在使用股票Linux的系统上一样。uclinux驱动程序的编写是否有显著差异？例如，kmalloc的不同实现，或者细节都是在幕后处理的，我不需要为它操心？@标记ucLinux的酷之处在于，关于系统API（kmalloc（）等）的内核实现的大部分细节都已经处理好了。因此，即使不是所有的驱动程序源代码都与股票Linux相同，也有很大一部分是相同的。然而，我们（几年前）遇到的一个问题是，支持Atmel处理器的最新版本的ucLinux是基于2.4.x内核的，并且该处理器无法使用或甚至不可能使用2.6.x端口。您可能需要检查您选择的处理器是否有最新的ucLinux内核版本，或者选择一个可以工作的处理器。我询问差异的原因是在“内存分配”一节中提到了kmalloc2（）API，但我在代码中没有找到。