Drivers in a monolithic kernel

[nullify]

My understanding is that most monolithic kernels have their drivers linked in at run-time (DLLs, loadable kernel modules, whatever). Supposedly this means all kernel symbols are visible to each driver, making it difficult to add/change/remove kernel symbols without correcting any drivers that use them as well. Off the top of my head, I can think of two solutions:

- Drivers are restricted to using a well defined "driver API" to access kernel functionality. No attempt should be made by drivers to access internal kernel symbols that may vary between revisions.
- Drivers reside in a separate address space from the kernel (not necessarily in user space, though).

What do you think? Is this common or am I off track here?

[Tim]

I prefer the first one. Run-time linking doesn't mean you have to export all kernel symbols to drivers, if your executable format supports selective exporting of symbols.

Alternatively, you could just give driver developers a list of supported functions, and ask them not to use any others.

[nullify]

Run-time linking doesn't mean you have to export all kernel symbols to drivers, if your executable format supports selective exporting of symbols.

Wow, I didn't know that was possible. Do you happen to know if it could also work the other way around (so as to prevent device drivers from polluting the kernel namespace) ?

[Tim]

Yes. You write the run-time linking code, so you decide what has access to what symbol.

[mystran]

Indeed, since the linking code is likely to be home-grown, one could even use some kind of

Code: Select all

struct symbols_t { char * symbol; void * func; } symbols [];

or such and use that to resolve symbols, even when the executable format itself didn't support selective symbols.

[Tim]

The total of my PE code is one file of a couple of hundred lines. It's not hard to load PE files at runtime and look up the addresses of named exports. If you build your kernel as PE, the kernel itself can export the device driver interface.