In Linux, from http://www.mulix.org/lectures/intro_to_linux_device_drivers/intro_linux_device_drivers.pdf

user programs talk with device drivers through device files

But if I understand correctly,

  • if the device driver is inside the OS kernel, a user program accesses the device, by making system calls to request the OS kernel to act on its behalf. How do the device file and system calls work together then, since they both help the user program to access the device? (Does the device file act both as an id to the device and also as the interface to the device driver?)

  • If the device driver is outside the OS kernel, does the user program only use the device file to access the device, without system calls?



The user mode program always uses system calls to communicate with the hardware. The device file exists solely so that the program can use well-known, simple, standard system calls to get the job done rather than complicated device-specific ones.

Basically, reading and writing a device file involves exactly the same system calls open(), read(), write()` etc. as reading from a vanilla text file. Since many programmers already know how to do this, this makes controlling a device relatively easy - you only have to know the device node name and the protocol for talking to it, rather than the special verbs for programming your snazzy TV tune card.

With a user-space driver you can in principle allow the user space program to use a more complicated way of talking to the driver, but why would you want to? Device files bring a great reduction in complexity for a moderate loss in expressivity, so they are usually preferred. That way only driver programmers have to delve into the intricacies of the specific card.

  • thanks. How do drivers and device files work together? (1) do you mean drivers provide abstraction of devices, and device files provide abstraction of drivers? (2) if the driver is not inside the OS kernel, does a user program still access the device and driver through a device file? – Tim Feb 4 '15 at 14:40
  • (1) Yes, there are multiple levels of abstraction going on, and each of them is actually useful. (Driver authors need a bit of simplification too, they're just good, not superhuman.) (2) I'm guessing yes, but I'm not systems-level savvy enough to say whether that is always or even mostly true. – Kilian Foth Feb 4 '15 at 14:51
  • (2) Clarify my questions: if the driver is not part of the OS kernel, will there still be a device file for the driver? Is a device driver only supplied by the kernel? – Tim Feb 4 '15 at 14:55

A file handle is an abstraction, even for a regular text file. When the user performs a read system call, a lot happens inside the kernel. To the user, it looks like you're reading consecutive bytes from a disk, but those bytes might be on separate disks on separate computers, or in various levels of memory cache. The kernel has to find the best place to retrieve those bytes and return them to the user space.

There's nothing particularly special about bytes on a disk. If your device is a mouse, the read system call inside the kernel might query the hardware to get the current position of the axes, and the state of the buttons. Thus, the "file" the user reads contains a struct with that information, repeated over and over. It allows the user to use the same system calls. They only need to learn the struct format, which is usually provided in a header file.

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.