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?
Thanks.
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.
3
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.