OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 4:11 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: Driver discovery
PostPosted: Thu Sep 18, 2014 11:33 am 
Offline

Joined: Wed Sep 05, 2012 7:13 am
Posts: 8
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?

_________________
Any resemblance of my madness to methods, useful or flawed, is purely coincidental.


Top
 Profile  
 
 Post subject: Re: Driver discovery
PostPosted: Thu Sep 18, 2014 12:25 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Driver discovery
PostPosted: Thu Sep 18, 2014 1:15 pm 
Offline
Member
Member

Joined: Mon Jan 03, 2011 6:58 pm
Posts: 283
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


Top
 Profile  
 
 Post subject: Re: Driver discovery
PostPosted: Fri Sep 19, 2014 1:34 am 
Offline
Member
Member
User avatar

Joined: Thu Jul 26, 2007 1:53 am
Posts: 395
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.

_________________
Fudge - Simplicity, clarity and speed.
http://github.com/Jezze/fudge/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 23 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group