Are drivers complete programs?

[chrstrbrts]

Hello,

Are drivers complete programs that run from start to finish like user applications?

Or, are drivers just libraries of data and functions?

I think that they are libraries and not complete programs, but I'm not sure.

If they are just libraries, then how does the processor know which functions and data to call out to?

As far as I know, the interrupt handler sets the voltage high on an interrupt line.

But how does the processor know where the interrupt came from and what the interrupt was for exactly?

Thanks.

 

[Merad]

Libraries.

The latter question is something that becomes very complex. The short version (and I don't really know all the details) is that there is more than one interrupt built into the CPU. AFAIK whenever possible operations are offloaded from the main CPU to the motherboard's chipset or another off-die controller that transfers data via DMA, which then sends an interrupt to the CPU when the operation is complete. The CPU calls an interrupt handler that was set up by the operating system when the OS booted. If the OS handler can't/doesn't handle the event itself it will call or otherwise notify the driver code which will handle the event.

In a grad school operating systems class we wrote a simple "driver" for the Minix OS. Minix is an OS that works entirely via pieces of the OS passing messages to one another. We wrote our functions that handled the driver operation, then set up a system call so that other code could send a message to our driver to ask it to take action. Our solution involved directly modifying and recompiling the operating system kernel. A real OS will dynamically register/unregister driver handlers.

 

[wiseguyin]

As merad pointed out, they are libs. Both on Windiows as well as linux. Since Apple is a descendent of the *nix family (I think BSD), they can be libs (shared objects) on it too. Wonder if iPhones use the same kind of drivers. Not very sure about that.

 

[chrstrbrts]

If the OS handler can't/doesn't handle the event itself it will call or otherwise notify the driver code which will handle the event.

So, the interrupt handler and driver are not the same thing?

A real OS will dynamically register/unregister driver handlers.

How does the OS accomplish this?

 

[Merad]

So, the interrupt handler and driver are not the same thing?

No. Most drivers today are run in user mode so that a driver crashing can't take down the system, and so there's less chance of security holes in drivers. If you've used windows for a while you've probably seen a BSOD with the error IRQL_NOT_LESS_OR_EQUAL - that's what you typically get when a kernel mode driver breaks.

The interrupt handler would be implemented as part of the OS kernel, which will talk to the driver via messages (or something similar).

How does the OS accomplish this?

Let's say I'm writing a program that I want you to be able to extend with plugins. I design certain functions that a plugin author implements to load, unload, and send information to a plugin. They then compile their code with these function into a DLL, and place the DLL in a particular folder. As part of my program start, I will scan through the files in that folder, check if they are DLLs, and check if the DLL contains those functions I specified. If it does, I will keep that DLL loaded as part of my program and call its functions to manipulate the plugin.

Conceptually drivers work in basically the same way, but at least in windows they are (AFAIK) built on top of Microsoft's Component Object Model (COM).

 

[chrstrbrts]

If you've used windows for a while you've probably seen a BSOD with the error IRQL_NOT_LESS_OR_EQUAL - that's what you typically get when a kernel mode driver breaks.

Is it ever possible for a system to recover from a ring 0 error?

How might a driver error crash the whole kernel?

Thanks.

 

[Merad]

Sure, there are recoverable errors.

When you allocate memory (aka "new" in Java), you're talking to a user-mode memory allocator that's usually built into the standard library of your language. That allocator asks the kernel for big chunks of memory, and then breaks them up into smaller pieces to fill your requests. When the user-mode allocator runs out of memory, it has to ask the kernel for more. If the kernel can't find enough free memory pages to fill the request, it will try to free up some memory by evicting pages to the hard drive (paging). If for some reason that fails (e.g. you've turned of the page file in windows), then the state of the system is broken, and you'll get a nice kernel panic or BSOD.

Often the problem isn't that things are completely broken, just that you aren't sure. The problem with kernel mode drivers is that they can basically do anything. By the time you detect one problem, there's a good chance there are other problems. Forcing a reboot is the only safe option - trying to continue risks data corruption or allowing security vulnerabilities.

 

[chrstrbrts]

Thanks, guys.

 

[Mike64]

But how does the processor know where the interrupt came from and what the interrupt was for exactly?

For hardware interrupts, there'll also be an address given to identify the hardware unit initiating the interrupt. This 3 page summary highlights the most basic aspects of interrupt handling. It's an old document, but the basic concepts underlying interrupts haven't really changed.