用户空间与内核空间驱动程序 [英] Userspace vs kernel space driver
问题描述
我正在寻找编写PWM驱动器.我知道我们可以通过两种方式控制硬件驱动程序:
I am looking to write a PWM driver. I know that there are two ways we can control a hardware driver:
- 用户空间驱动程序.
- 内核空间驱动程序
如果通常(不考虑PWM驱动器的情况)，我们必须决定是使用用户空间驱动程序还是内核空间驱动程序.那么除了这些之外，我们还必须考虑哪些因素?
If in general (do not consider a PWM driver case) we have to make a decision whether to go for user space or kernel space driver. Then what factors we have to take into consideration apart from these?
- 用户空间驱动程序可以直接mmap()/dev/mem内存到其虚拟地址空间，而无需上下文切换.
- 用户空间驱动程序无法实现中断处理程序(必须轮询中断).
- 用户空间驱动程序无法执行DMA(因为可以从内核空间分配支持DMA的内存).
推荐答案
从列出的这三个因素来看，第一个实际上是正确的.至于其余的-并非如此.用户空间代码可以执行DMA操作-没问题.有许多硬件设备公司在其产品中采用了此技术.即使所有I/O是通过完整的内核旁路完成的，也可能具有中断驱动的用户空间应用程序.当然，简单地在/dev/mem上执行mmap()并不是那么容易.
From those three factors that you have listed only the first one is actually correct. As for the rest — not really. It is possible for a user space code to perform DMA operations — no problem with that. There are many hardware appliance companies who employ this technique in their products. It is also possible to have an interrupt driven user-space application, even when all of the I/O is done with a full kernel-bypass. Of course, it is not as easy simply doing an mmap() on /dev/mem.
您必须在内核中保留驱动程序的一小部分，这是必需的，以便为您的用户空间提供内核所需的最小空间(因为考虑到这一点，/dev/mem是也由字符设备驱动程序备份).
You would have to have a minimal portion of your driver in the kernel — that is needed in order to provide your user space with a bare minimum that it needs from the kernel (because if you think about it — /dev/mem is also backed up by a character device driver).
对于DMA来说，这实际上太简单了-您要做的就是处理mmap请求并将DMA缓冲区映射到用户空间.对于中断-有点棘手，无论如何都必须由内核处理中断，但是，内核可能无法执行任何工作，只是唤醒了调用epoll_wait()的进程.另一种方法是像DOSEMU一样向过程传递信号，但这很慢，因此不建议这样做.
For DMA, it is actually too darn easy — all you have to do is to handle mmap request and map a DMA buffer into the user space. For interrupts — it is a little bit more tricky, the interrupt must be handled by the kernel no matter what, however, the kernel may not do any work and just wake up the process that calls, say, epoll_wait(). Another approach is to deliver a signal to the process as done by DOSEMU, but that is very slow and is not recommended.
对于您的实际问题，您应该考虑的一个因素是资源共享.只要您不必在多个应用程序之间共享设备，并且在用户空间中没有什么是您无法做的，那就去用户空间吧.由于编写用户空间代码非常容易，因此您可能会在开发周期中节省大量时间.但是，当两个或多个应用程序需要共享设备(或其资源)时，您很可能会花费大量时间使之成为可能-想象一下多个进程同时分叉，崩溃，映射(相同?)内存等毕竟，IPC通常是通过内核完成的，因此，如果应用程序需要开始彼此对话"，则性能可能会大大下降.不过，对于某些对性能至关重要的应用程序，仍然可以在实际操作中完成此操作，但是我不想赘述这些细节.
As for your actual question, one factor that you should take into consideration is resource sharing. As long as you don't have to share a device across multiple applications and there is nothing that you cannot do in user space — go for the user space. You will probably save tons of time during the development cycle as writing user space code is extremely easy. When, however, two or more applications need to share the device (or its resources) then chances are that you will spend tremendous amount of time making it possible — just imagine multiple processes forking, crashing, mapping (the same?) memory concurrently etc. And after all, IPC is generally done through the kernel, so if application would need to start "talking" to each other, the performance might degrade greatly. This is still done in real-life for certain performance-critical applications, though, but I don't want to go into those details.
另一个因素是内核基础结构.假设您要编写网络设备驱动程序.在用户空间中这样做不是问题.但是，如果这样做，则还需要编写一个完整的网络堆栈，因为将无法使用Linux的默认内核(位于内核中).
Another factor is the kernel infrastructure. Let's say you want to write a network device driver. That's not a problem to do it in user space. However, if you do that then you'd need to write a full network stack too as it won't be possible to user Linux's default one that lives in the kernel.
我想说的是，如果可能的话，请去用户空间，并且使事情正常进行的工作量少于编写内核驱动程序，并且要记住，有一天可能有必要将代码移入内核.实际上，这是一种常见的做法，因为是否在某些宏中定义了针对用户空间和内核空间编译相同的代码，因为在用户空间中进行测试会更加轻松.
I'd say go for user space if it is possible and the amount of effort to make things work is less than writing a kernel driver, and keeping in mind that one day it might be necessary to move code into the kernel. In fact, this is a common practice to have the same code being compiled for both user space and kernel space depending on whether some macro is defined or not, because testing in user space is a lot more pleasant.
这篇关于用户空间与内核空间驱动程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
