OSDev.org

I'm wondering how different OS go about deciding which drivers to load at boot time, particularly for microkernels, and whether my devices and drivers stuff is sensible.

As far as my system is concerned a driver is just another service exposed through the kernel's IPC layer. I have a few very basic drivers which are actually in the kernel itself, and once the real user-mode driver is ready it takes over that functionality (I also have a slightly hacky API for transferring the driver state from the early to full drivers so that I can avoid reinitializing things). The relevant part of the startup process is:

- The kernel starts process0
- Process0 starts the namespace service. The namespace service supports (initially empty) namespaces for devices and files.
- The namespace service takes over control of the initial ramdisk from the kernel. It becomes the first device in the device namespace, and the contents of the ramdisk become the first nodes in the files namespace.
- Process0 then starts the device discovery service. This queries ACPI via the kernel to find out what buses we have, and then recursively starts loading and querying bus drivers and device drivers, populating the device namespace as it goes (and files namespace if we hit a mountable volume). Devices for which a driver is not available still get added to the device namespace so that if a driver becomes available later it just attaches itself to the correct node.

So far so good, but how do I know they're there when I discover a mountable volume with more drivers on it? Or choose between them if I have multiple drivers available? The obvious thing seems to be keeping some sort of mainfest in a well-known location on a volume which has drivers, but that seems (a) inelegant, and (b) a security risk.

I'm just kinda talking this through for myself really, but any ideas?

Hi,

twrl wrote:So far so good, but how do I know they're there when I discover a mountable volume with more drivers on it?

In general, I like the "pull" model where it's a hierarchical tree, and the parent is responsible for "pulling in" any children. For example:

• PCI bus enumeration might find a USB controller, a video card and a network card and start those drivers.
  • The USB controller driver might enumerate USB devices, find a mass storage device and a keyboard and start those drivers.
    • The USB mass storage device driver might find 3 partitions, determine their file systems and start them.
      The USB keyboard driver might start the virtual terminal layer.
    The video driver might detect a monitor and try to start the virtual terminal layer (and find it already started by keyboard).
    The network card might start a TCP/IP stack
    • TCP/IP stack might start a HTTP server
    The virtual terminal layer (after getting enough devices for input and output) starts a login prompt.
    • The login prompt (after successful login) starts the user's GUI.

twrl wrote:Or choose between them if I have multiple drivers available?

If there are multiple drivers, choose the most specific driver. For example, if there's a "generic OHCI USB controller driver" and an "vendorID 0x1234, deviceID 0x1234 OHCI USB controller driver" you'd choose the one with the matching vendorID/deviceID where possible. If there are multiple device drivers with equally specific details, then complain that the OS failed to uninstall one before the other was installed (e.g. add a warning to your logs or something), then start the driver with the most recent time stamp.

Also note that I'd setup the file system's directory structure to suit the search order - e.g. a directory for each "PCI class ID"; containing none or more directories for "vendor ID", etc. You'd search for the file "class_0x0033/vendor0x1234/device0x1234.drv"; then "class_0x0033/vendor0x1234.drv"; then "class_0x0033.drv". This makes it impossible to have multiple drivers with equally specific details.


Cheers,

Brendan

twrl wrote:So far so good, but how do I know they're there when I discover a mountable volume with more drivers on it?

Only run drivers from trusted, known locations. Otherwise someone can just plug a thumbstick into your PC running your OS and install "drivers" that are nothing but malware or worse.

- Monk

I use kernel modules for all my drivers and that forces you to use another method of discovery but basically produces the same end result.

When loading a module from userspace you have to make sure that if that module requires another module, that has to be loaded first. You can handle that either manually or make a list of module dependencies in a file that you parse before loading the module.

If the module in question is for a bus lets say pci, then it would register some sort of scanning function in the kernel that would enumerate all available devices for that bus. Later when you load a module for say a network card it would use this scanning function to see if the bus has a device that matches a criteria say have a certain pci vendor and device id and then attach itself to that device by registering itself.

So how would you know how to autoload a specific driver? Every time a bus discovers a device it could print the relevant information to a log which from userspace can be monitored. For each entry a monitoring program would look at that entry and try to find a matching module. It would also be this monitor that would decide the module priority in the same way Brendan described.