I am trying to understand how Device Drivers work, based on what I know so far, a Device Driver is simply a "middle-man" between the Operating System and the Device. I have created the following diagram to show my understanding of Device Drivers:

enter image description here

Also, an Application cannot interact directly with a Device Driver, only the Operating System can do that (so for example, if an Application wants to print something, it "tells" the Operating System, and the Operating system tells the Device Driver).

Is my understanding correct? And is the concept of Device Drivers the same on Windows and macOS as it is on Linux?

  • You'd probably better use something other than various kinds of printers as an example of "device drivers". At the kernel level, device drivers don't really care about or have knowledge of different kinds of, say, printers. That happens at a much higher level, in userspace. In fact, while the kernel does know about such a thing as, for example, a USB printer versus a serial printer, it knows nothing at all about, say, a TCP/IP printer. In short, when you're talking about printers, you're not at all talking about [kernel] device drivers.
    – Celada
    May 12 '17 at 19:29
  • 1
    You can try to read a little bit of that book : lwn.net/Kernel/LDD3 It's for an old version of the kernel, but it shouldn't have changed much. I guess chapter 1 will help you understand the fundamental notions. May 15 '17 at 13:00

Very briefly:

The most important thing about a device driver is that it runs in kernel space, with the same permissions as the kernel, and therefore can access hardware directly. Applications are (usually) not permitted to do that.

So you can think of device drivers as the parts of the kernel that organize access to certain hardware (the "device").

An application can interact with the kernel on various levels: From higher abstractions (e.g. a file system) to middling abstractions (a block device) to really low level abstractions (some files in /proc/ or /sys, some ioctls in devices in /dev). So the low level interactions will sometimes be talking to a device driver very directly, there's only a very thin layer where the kernel redirects the call to the device driver. So "an Application cannot interact directly with a Device Driver, only the Operating System can do that" is sort of true and also sort of false.

Also, there are many abstraction layers in the kernel like the one you describe in your picture ("the messages the OS sends are the same, the device driver uses differnent messages to talk to the hardware). For example, the block layer receives one kind of messages, but passes them on to different block devices. The USB layer receives one kind of messages, but can use different USB host controllers. And so on.

So the picture is much more difficult, there are layers and subsystems in the kernel, and the device drivers that actually talk to the hardware are at the bottom of that hierarchy. To confuse things more, both the device drivers and other layers come in the form of modules (for Linux). If you type lsmod, you can see which modules are active, and which module uses which other modules.

Also, printing is a very bad example; most of the printer-specific processing happens in user space, and not in a device driver.

All of Windows, Linux and MacOS follow these principles, but the details are very different.

Does that help?


Printing on Linux is today usually done with cups. Cups has a collection of programs that can render documents for various printers. All of these programs take a file (the document as pdf/postscript/...) and convert it to another file in a format the printer understands. All of this happens outside of the kernel, because none of this needs to access actual hardware. It just reads and writes files. Only the very last part, when the converted data is sent to the printer, uses the kernel. And then it can uses various paths, even for the same type of printer: via the network, via USB, via a serial connection, etc. And this last part often isn't printer specific.

So Linux doesn't really have printer-specific device drivers for the large majority of printers. (For a few printers, you may need one).

  • This was very helpful. But I did not quite understand what you mean by "most of the printer-specific processing happens in user space, and not in a device driver". May 19 '17 at 23:50
  • this is merely contextual problem which OP used printer as example of device driver but dirkt means that if you want to talk about device driver talk on kernel space, not in user space (printer) IMHO
    – evanhutomo
    Jan 15 '20 at 5:48

a Device Driver is simply a "middle-man" between the Operating System and the Device.

Yes, that's more or less it.

Device drivers are "black boxes" that translate standardized programming calls to device-specific operations of the hardware component.

In this way, a program doesn't need to know the inner workings of a specific piece of hardware; it's the specific device driver that will do the mapping in a transparent way, allowing the program to "talk" with the hardware.

They are built separately from the kernel, and activated (as modules loaded into the kernel) when needed.

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.