6

I have been reading "Linux Device Drivers" by Jonathan Corbet. I have some questions that I want to know:

  • What are the main differences between a user-space driver and a kernel driver?
  • What are the limitations of both of them?
  • Why user-space drivers are commonly used and preferred nowadays over kernel drivers?
iqstatic
  • 2,322
  • 3
  • 21
  • 39
  • That does not answer all my questions. –  Oct 22 '14 at 11:36
  • Which question does it not answer? – code monkey Oct 22 '14 at 11:38
  • 2nd and 3rd. Limitations and preference. –  Oct 22 '14 at 11:39
  • Kernel mode drivers don't have any limitations, they can do everythig a user mode driver can do. – simonzack Oct 22 '14 at 11:43
  • Then what are the limitations of user-space drivers? Why are they preferred nowadays? –  Oct 22 '14 at 11:44
  • They are 'prefered' nowadays bcos the kernel devs dont want the kernel to get messed up. When stuff is developed for the kernel, it needs to be aware of many things , for example; Read this-Structural Differences Between Kernel Modules and User Programs The following characteristics of kernel modules highlight important differences between the structure of kernel modules and the structure of user programs: Kernel modules do not define a main program. Kernel modules, including device drivers, etc,etc ... Taken from -> https://docs.oracle.com/cd/E19253-01/817-5789/emjjr/index.html – MarcoZen Nov 26 '14 at 03:02

1 Answers1

14

What are the main differences between a user-space driver and a kernel driver?

User space drivers run in user space. Kernel drivers run in kernel space.

What are the limitations of both of them?

The kernel driver can do anything the kernel can, so you could say it has no limitations. But kernel drivers are much harder to "prove correct" and debug. It's all-to-easy to introduce race conditions, or use a kernel function in the wrong context or with the wrong locking. Things will appear to work for a while, but cause problems (including crashing the whole system) down the road. Drivers must also be wary when reading all user input (both from the device and from userspace) because invalid data can sometimes cause crashes.

A user-space driver usually needs a small shim in the kernel to do it's bidding. Usually, that 'shim' provides a simpler API. For example, the FUSE layer lets people write file systems in any language. They can be mounted, read/written, then unmounted. The shim must also protect the kernel against all invalid input.

User-space drivers have lots of limitations. For example, the kernel reserves some memory for use during emergencies, but that is not available for users-space. During memory pressure, the kernel will kill random user-space programs, but never kill kernel threads. User-space programs may be swapped out, which could lead to your device being unavailable for several seconds. (Kernel code can not be swapped out.) Running code in user-space requires several context switches. These waste a "lot" of CPU time. If your device is a 300 baud modem, nobody will notice. But if it's a gigabit Ethernet card, and every packet has to go to your userspace driver before it gets to the real user, the system will have major bottlenecks.

User space programs are also "harder" to use because you have to install that user-space software, which often has many library dependencies. Kernel modules "just work".

Why user-space drivers are commonly used and preferred nowadays over kernel drivers?

The question is "Does this complexity really need to be in the kernel?"

I used to work for a company that made USB dongles that talked a particular protocol. We could have written a full kernel driver, but instead just wrote our program on top of libUSB.

The advantages: The program was portable between Linux, Mac, Win. No worrying about our code vs the GPL.

The disadvantages: If the device needed to data to the PC and get a response quickly, there is no guarantee that would happen. For example, if we needed a real-time control loop on the PC, it would be harder to have bounded response times. (Maybe not entirely impossible on Linux.)

If there is a way to do it in userspace, I would try that first. Only if there are significant performance bottlenecks, or significant complexity in keeping it in userspace would you move it. Even then, consider the "shim" approach, and/or the "emulator" approach (where your kernel module makes your device look like a serial port or a block device.)

On the other hand, if there are already several kernel modules similar to what you want, then start there.

BraveNewCurrency
  • 12,654
  • 2
  • 42
  • 50