Say I have a device that is connected to the computer through a USB port, and I created an application to communicate with this device. In this application I used the USB driver to communicate with the device.

Then later I decided that I don't want my application to communicate directly with the USB driver, so I removed the code that communicates with the USB driver from my application and created a device driver that contains this code, and so now my application will communicate with the newly created device driver.

Now I have read that device drivers in Linux need to run in kernel mode. But why is that?

I mean when my application communicated directly with the USB driver, it was running in user mode. So why when I moved the code that communicates with the USB driver to the device driver, now the device driver needs to run in kernel mode, why can't the device driver also run in user mode?


The moved code could still run in userland, it just wouldn't be a driver, it would be a library or similar. I believe your so-called driver is misnamed and is in fact not a driver, just an intermediate shared library or some such.

Device drivers are able to access privileged functions and have access to stuff userland software is not. That is why they have to be in kernel mode. That's also why they are more scrutinized and more difficult to load and run, because of the trouble they could cause. Dodgy drivers are capable of deadlocking a system and can make the system unstable, with no way for the OS to shut it down.

If you have a set of code that doesn't require that privileged access, it's pointless to build it into a driver. It would be like trying to get a building permit before moving furniture, a lot of hassle for no benefit.

| improve this answer | |
  • "The moved code could still run in userland, it just wouldn't be a driver, it would be a library or similar" So all the drivers that run in user mode are called a library or similar and not a driver?! – John May 29 '17 at 11:13
  • @John, no, yours wouldn't be a driver because it never was in the first place. – whatsisname May 29 '17 at 14:11
  • Why the driver I created wouldn't be called a driver, I mean it is communicating with the device after all. Do you mean that my driver should communicate with the USB controller directly (instead of communicating with the USB controller driver) to be called a "driver"? – John May 30 '17 at 1:38
  • @John: No, to be a driver you need to be involved with bridging the gap between hardware and userland applications. In the case of USB it's complicated because USB is complicated. Some USB drivers only provide API endpoints to other drivers. If you want to really understand this you need to take a stab at implementing it. Use an Adafruit trinket or something, use the Windows DDK, and try to implement a custom device class. – whatsisname May 30 '17 at 2:02
  • Ever heard of TUX and other in-kernel webservers? – Deduplicator Jun 18 '17 at 0:19

Device drivers don't need to run in kernel mode in Linux. It is perfectly possible to run drivers in user mode.

For example, the libusb library's purpose is to write OS-independent USB drivers in user mode. Almost all printer drivers are in user mode. Parts of the graphics stack are in user mode (although how much of it and where the boundaries are tends to shift around every 10-15 years). FUSE's purpose is to write file system drivers in user mode.

If you're asking more generally why device drivers have to be in kernel mode, the answer is: they don't. In monolithic kernels such as Linux, they tend to be, but for example in microkernels, only a minimal functionality (virtual memory, task scheduling) is provided by the kernel and all the rest is implemented in user space. In nanokernels and exokernels even less is in the kernel: basically, the only thing the kernel does is sequencing access to resources. It doesn't even manage memory.

And last but not least, there are no-kernel OSs, where there isn't even a kernel: everything runs in user space.

| improve this answer | |
  • While what you have written is true, I think blurring the picture will confuse the OP. – whatsisname May 29 '17 at 4:37

Now I have read that device drivers in Linux needs to run in kernel mode. But why is that? ... why can't the device driver also runs in user mode?

Drivers run in kernel mode while applications run in user mode for many reason. For example

  • a driver has need of high priority to service device I/O in a predictable manner (and otherwise can risk loosing some data). For example, drivers may need to run without incurring page faults. Putting driver memory in the kernel is one easy way of accomplishing this. (In truth, this is, of course, much more complicated: usually drivers have a small amount of super high priority code along with some less critical additional code that also runs in the kernel, and the two share memory.)
  • I/O instructions and device memory mapped I/O addresses are typically protected from application code, so applications are not allowed direct access to these resources. Forcing applications to use kernel/system calls allows the operating system to share devices between multiple applications, or even multiple virtual machines.
  • Having applications use a kernel/system read/write interface to access devices allows device substitution and upgrading device drivers independently from the application.

Applications, by contrast, typically run in user mode, with a degree of abstraction from the underlying devices and their implementation.

I mean when my application communicated directly with the USB driver, it was running in user mode.

Yes, but the application's communication with the USB driver is done via kernel/system calls, so the kernel is involved in this. Further, the USB driver itself is typically in the kernel; just library routines to access them are in the application or application-used libraries.

If you write your own device driver, you could put all your application's functionality into the device driver and thus not require a user mode application at all. However, that is generally not a great structuring of functionality for a number of reasons. Guidelines like Separation of Concerns would be violated, for example.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.