3

In Linux, does a user program always use system calls to the OS kernel, to access a device driver indirectly?

When the driver is implemented as a module which can be loaded and unloaded, does a user program access the driver directly without making a system call to the kernel?

4

The user calls library functions that wrap around the system calls (raw syscall is quite rare for a normal programmer). The module code runs in kernel mode anyway, so at some point, there must be a context switch from user space to kernel space. Ideally, most modules will use standardized interfaces (device nodes, netlink sockets, even inet sockets), so that the interaction from the user side will be mostly through read() and write() system calls (ioctl is also quite common, as it covers the "extra" settings that don't fall under standard systemcalls). Buffers will diminish the number of calls, but at the end there's always a system call involved.

3

Kernel modules exist in kernel space and therefore by definition require system calls in order to be accessed from userspace, so yes with regard to them.

However, it is possible to create userspace drivers that are built on top of some kernel one, although in the end they must make system calls to operate. This is possible with, e.g., I2C devices; the userspace driver uses the kernel's SMBus API (which is all system calls). In that case some application might technically use some facility of the driver without passing through the system, but if the driver must actually interact with the hardware, then it's system calls again.

It's also possible to use mmap() (a system call) on /dev/mem, which is the system memory (see man mem) and, since this includes the entirety of kernel space, exposes access to hardware. Manipulating this map then does not require any further system calls. I believe this is an unusual thing to do, partially because it sidesteps the kernel itself in a way that might be undesirable, and partially because making it portable from one architecture to another would involve redundancy1 -- so it is more likely to be used for hacking and experimentation than driver deployment in production systems.

Kernel drivers can expose a device node based interface to userland, which might be operable using read() and write() -- which are system calls.


1. If you write a normal kernel driver, or use a kernel userland API, the kernel itself covers portability issues; you can stick with one version of your code. If you use the memory mapping method, you'll have to have different versions of your code for every architecture (which the kernel already has, hence "redundant").

  • For some devices on some architectures, it's possible to allow userland processes to map the hardware and thus read or write the peripheral's registers directly. I don't know if Linux ever does that or if there's always a call through the kernel. – Gilles Feb 4 '15 at 22:26
  • @Gilles You can mmap /dev/mem that way on linux, yeah -- added a paragraph about this. – goldilocks Feb 5 '15 at 4:08
  • 1
    There are also "cached" syscalls that don't actually switch context. gettimeofday is one of them. Read lwn.net/Articles/220913 – orion Feb 5 '15 at 8:02

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.