OSDev.org

Hi All,

Up until now, I have had basic keyboard, video (TUI) and serial (debugging) drivers built in to my kernel.

I have got to the stage now where I am thinking about the future, when some or all of these drivers will need to be replaced with more complex versions (although I guess there is only so much you can do with a com port!).

So, if I am thinking about writing a driver interface from scratch, how do I go about it? I know a lot of this will be 'do whatever you want for your os', but at the moment, I have no idea about how to implement fast communication between my kernel and drivers, or how to make the drivers extensible / replaceable.

I have read the IPC and hardware articles on osdev but my problem isn't so much about how to write the driver, as the interface. Any thoughts / pointers to samples would be much appreciated. Meanwhile, I'll be trawling though some of the osdev users' home pages to see how they do it!

Cheers,
Adam

Hi,

I'd recomend starting with some basic desicions...

First, which resources will be protected? For a monolithic OS (with or withour dynamically loaded modules) the answer here is "none". For a micro-kernel the answer is typically "everything" (I/O ports, IRQs, memory mapped I/O ranges, PCI configuration space, etc).

Next, decide what is responsible for detecting if devices are present and configuring/detecting which resources the device uses. For some OSs the device driver itself detects if the device is present, configures/detects the device's resources and then tells the OS what resources it needs (which makes it impossible to securely protect resources, and means that the OS needs to start all device drivers to figure out what is or isn't present). I typically use a "device manager" which is responsible for the detection/configuration of devices, where the device driver isn't started unless the device is present, and the device driver is told which resources it must use by the device manager.

After these you need to figure out what sort of interface the device drivers use - is it IPC (typical for micro-kernels), or is the device driver dynamically linked to the kernel (or able to directly call kernel functions)?

Lastly, you need to start thinking about what device types you will have, and defining an interface for each device type. For some OSs there is only one or 2 device types ("everything is a file" or "everything is an OOP object"). Alternatively you could have (for e.g.) one device driver interface for storage devices, one for netowork devices, one for human interface devices, one for video, one for sound, etc.

When you're defining the interface for each device type, don't forget that it should include a way of "connecting" to what-ever code is above the device driver. For example, a video device driver might interface to a GUI and nothing else and you'd need to define how the video driver tells the GUI it's present and ready for operation. A network device driver might interface to code that supports the TCP/IP stack, and a storage device driver might interface to some file system code (or the VFS, depending on your OS design).

BTW for all of the above there is no "right" or "wrong" way (just different advantages and disadvantages), but these decisions make a huge difference to the final OS and how the individual device driver interface/s are designed....


Cheers,

Brendan

Thanks for the summary - big help!

I was sort of thinking along the device manager route that you describe and protection is a definite. I think I am going to start playing with code and thinking what needs to happen.

I also think that I am going to need some kind of mode system like linux - ie, start in kernel mode where the kernel has direct control of the GUI (complete with it's own printf etc... which I already have for debugging).

When the device manager (which I am thinking of building directly in my kernel) takes over, I switch to an external mode where the kernel should no longer attempt to directly write to video memory areas etc - it also has to go through the driver to ensure that it works with any future GUI.

Of course, in the event of a panic situation, I then need to be able to switch back to kernel, text mode VGA so that the appropriate dumps etc... can be performed.

Adam

For the interface itself you could have a look at the UDI Project. It tries to define a standard interface for device drivers. I'm not advocating the use of it, but it may give you some ideas as to how you might try defining it. I saw a thread not long ago about EUDI, you may also look at that for ideas.

The second one is mine, called EDI. See here.

Thanks. When I was starting with OS dev I heard about similar projects but as I hadn't written a line of code at that point, didn't pay much attention to the names or URLs.

I'll get reading!

Adam