Device driver interfaces revisited

[Jezze]

Hi,

Let's say I load a driver for a VGA framebuffer. I load the object file into memory, relocates it and points it's external references to the appropriate kernel functions so they are connected together.

The thing I can't figure out is the other way around. The kernel has no knowledge of what driver is used to print to the framebuffer so how does the kernel print stuff?

Reading about UDI and EDI didn't explain this to me.

[ErikVikinger]

Hello,


your driver must have an main-function and it must register the new driver at the kernel.
The kernel must have structures what are filled with the informations from the drivers.
With this information do find the kernel all needed drivers.


Greetings
Erik

[blobmiester]

The kernel shouldn't know which driver it uses to print something, correct. You need to give it an understanding of a device class such as a video adapter. So the kernel has a video adapter interface and all device drivers implement that interface. Then when you detect hardware at boot you can point the kernel's adapter interface to the apporpriate device driver for the video card you detected (probably vga_generic or simliar for a while )

For myself, all of my drivers are modules. And these driver modules contain a class dervied from the base class module. All video adapter drivers derive from the base class adapter. When I am detecting hardware, I load the appropriate driver module, which in turn either enumerates and loads more driver modules, or returns an instance of the module class. It's the enumerator's job to register the individual module class instance to the approriate locations in the system module. So if the PCI enumerator found a NVIDIA card and loaded the Generic VGA driver module. Then the PCI enumerator would execute the DT_INIT function of the module, get an instance to its module object, and register that instance with a static collection of video adapters. Later on, my console class, uses this adapter interface to print text to the screen.

Hopefully that helped somewhat. I might've rambled for a bit too much.

[Jezze]

Of course. Makes much sense. Thank you very much!

[rdos]

I have an init-procedure that is called as the driver is "loaded" (actually, it is not loaded from disc, but from the binary image file that is booted). This init-procuedure will setup (export) entry-points for other drivers, and entry-points for applications. It can also setup various callbacks, like callbacks when it is valid to create threads. The exported entry-points are called with macros in an include file. These macros look like 48-bit calls to a null-selector. They are patched (relocated) at runtime with the actual address (that the device-driver setup / export when it loaded).

Common interfaces (like video, file systems, audio, keyboard, mouse) have a general-purpose module that sets up the interface (mostly for applications), and then export some "hooks" for actual device-drivers. A device-driver will then register itself with the applicable interface module (for instance, a file system with register a set of functions to a virtual file system interface).

I do not link a large kernel, rather most of the functionality (including the above mentioned interfaces) are separetely compiled device-driver modules that can be added if needed. The kernel only deals with threads, processes, interrupts, and the registering scheme for services that device-drivers use.