Question about kernel/user drivers

leeghoofd · 2006-01-03 21:56:07

Hi,

I hope this is the correct forum to ask this question..

Just out of curiousity am I wondering how do drivers work in linux. When is a driver in the kernel and when is it run by a user? I read about for instance keyboard drivers from xorg, but how come they don't have to be in the kernel? Don't they need root access etc, to acces the hardware? For instance, I need to load video drivers with modprobe, so I guess that they are in the kernel instead of xorg?

I would appreciate it if someone could explain this

Thanks,
David

deficite · 2006-01-04 22:29:22

I've never developed drivers for linux nor have I edited the Linux source code, but from my understanding the driver just "goes" where it was designed to go. There are benefits and disadvantages to do different methods and some things you just HAVE to use a kernel module to do. One thing that will answer many of your questions is searching the web about how /dev works. In fact, I recommend doing that and then asking any questions about what you don't understand.

joe · 2006-01-05 00:02:35

Drivers are used as an interface to hardware devices. All hardware access is done through the kernel through the use of system calls (user level) and interrupts. Direct access to the drivers is only done by the kernel. The system calls are merely a user interface to the hardware (read(), write(), etc.)

What is meant by 'in the kernel' most of the time is that the driver is actually built in the kernel and it always 'loaded' whenever the kernel is in memory. One of the features of Linux is that drivers can be modules, and loaded into memory only when necessary. This is unlike Windows where drivers are always 'in the kernel' so installing a new driver requires a reboot to reload the kernel into memory along with the new driver.

Hopefully I'm not too far off, I'm not an expert. I'm sure there are others here that know far more than I do....perhaps they can correct me.

Komodo · 2006-01-05 00:22:27

joe wrote:

One of the features of Linux is that drivers can be modules, and loaded into memory only when necessary. This is unlike Windows where drivers are always 'in the kernel' so installing a new driver requires a reboot to reload the kernel into memory along with the new driver.

Nice explanation joe

soloport · 2006-01-05 15:20:54

A driver is just software that interfaces directly with the hardware. It's main job is to wiggle bits in hardware registers or read status bits out of registers and react to its findings.

In a multitasking operating system there are two levels of interrupt: Hardware and software. The hardware peripherals, like mouse, keyboard, etc., cause the hardware interrupts to occur, and the task manager uses a software interrupt mechanism to "slice time" between tasks. The driver needs to be somewhat aware of both. On the one hand, there's the ISR or Interrupt Service Routine that needs to get in and out as fast as possible and deal with hardware or real-time interrupts. You press a key on your keyboard and you've just caused an interrupt to occur. The ISR grabs the event and records it in a temp location.

The counterpart to the ISR is the rest of the driver code, which is aware of the space where the ISR may have put information. It grabs the keyboard byte out of the ISR queue and hands it to some higher-order part of the kernel for further processing. But it doesn't get to do this in a straightforward way. All the while it is trying to get the byte passed up the food chain, the task manager may be switching it out and switching in any number of other tasks for the processor to execute. Also, other hardware may fire off interrupts, inhibiting the keyboard communication routine's progress. Eventually, though, a byte makes its way up through the kernel level to an application (in this case, right now, it would be Firefox) and is handled in context.

If an ISR takes too long, a keystroke can be dropped, tasks can't be managed in a timely manner, the OS may seem to slow down or even lock up. This is why, on rare occasions, even Linux can lock up solid. What happens is, a hardware interrupt (e.g. sound card) has wrested control of the processor and for whatever reason won't give control back (e.g. it's waiting for the DSP to respond to a query and has not its own built-in timeout) i.e. a bad design. You may see this happen and still experience mouse movement, but all else seems locked up. That happens because hardware interrupts are typically hierarchical. (e.g. The mouse interrupt may have a higher priority than the sound card interrupt.)

Linux offers a very nice framework within which to plug in your driver. It makes the driver-maker's job relatively easy. About all one has to worry about is getting the hardware figured out correctly and to not spend too much time (i.e. too many instructions) inside the ISR. When compiling the kernel, you can choose to include a driver in the image or to have the OS pull it in as a module. In either case, the kernel needs to know where in memory it can call both the run-time (software interrupt) and real-time (ISR) routines. A module simply takes advantage of a special kind of "linking".

Anyhow... Guess I've rambled on enough about this. Hope it helps. Any other questions?

leeghoofd · 2006-01-06 11:53:13

Hi,

So is it for instance correct that the for the keyboard drivers, there is a little driver in the kernel that speaks with the hardware and there is a driver in xorg that speaks with hat driver in the kernel, like soloport explained (different layers). So that the xorg driver doesn't directly interact with the hardware but does higher level stuff such as keymaps?

That could explain how it is possible that xorg can be run by a non root user. (I guess normal users never can directly interact with the hardware?)

Deficite, do you mean that in the example above the xorg driver interacts with a device in /dev which is created by the little driver in the kernel?

Thanks for your explainations!
David

Komodo · 2006-01-06 12:38:49

That was a fantastic explanation soloport; good call =oD

soloport · 2006-01-07 06:23:10

leeghoofd wrote:

So is it for instance correct that the for the keyboard drivers, there is a little driver in the kernel that speaks with the hardware and there is a driver in xorg that speaks with hat driver in the kernel, like soloport explained (different layers). So that the xorg driver doesn't directly interact with the hardware but does higher level stuff such as keymaps?

Correct. In fact in a lot of architectures (e.g. Motorola PPC) the processor provides dual context environments: a "privileged" and a "user" environment. This makes it easier for the kernel developer to switch from kernel mode to user mode and keep certain things separated. The privileged mode usually handles the hardware, and the user mode handles almost everything else (including "root" privileges).

Often it is a simple "set-jump, long-jump" which handles switching from user mode to privileged mode, where needed.

leeghoofd wrote:

That could explain how it is possible that xorg can be run by a non root user. (I guess normal users never can directly interact with the hardware?)

Exactly. (Refer to SJ-LJ above, though, for the usual exception.)

Arch Linux

#1 2006-01-03 21:56:07

Question about kernel/user drivers

#2 2006-01-04 22:29:22

Re: Question about kernel/user drivers

#3 2006-01-05 00:02:35

Re: Question about kernel/user drivers

#4 2006-01-05 00:22:27

Re: Question about kernel/user drivers

#5 2006-01-05 15:20:54

Re: Question about kernel/user drivers

#6 2006-01-06 11:53:13

Re: Question about kernel/user drivers

#7 2006-01-06 12:38:49

Re: Question about kernel/user drivers

#8 2006-01-07 06:23:10

Re: Question about kernel/user drivers

Board footer