Re: [cdi-devel] Proposed Dynamic Driver Loading System

[Max Reitz <max@xxxxxxxxxx>]

So you want to create something like a new CDI header containing a list of
all available drivers or include this list in an existing header file? I
think I don't like this idea a lot. There are two problems I can think of
now. The first one is that I don't like the idea to put "driver-specific"
stuff into "generic" CDI header files. OK, maybe there is no other way to
keep it simple. But there's another problem: What about non-PCI drivers?
You said they might not fit in this list. And I'm sure they won't. Apart
from non-existing or non-working drivers such as USB, there are CDI drivers
that won't fit in this list (in my opinion). Think of ata. It doesn't need
to be a PCI device so how do you plan to start it? It would be possible to
create a new list of drivers to be started always.
Anyway, your list is not complete, there are also PCI drivers which are
capable of handling different devices just by identifying them on their
class code, subclass code and programming interface (i. e. USB host
controllers). So you need to add those fields to the list (but that just
by the way).
But let's continue that problem about non-PCI drivers and let's have a
look on those non-existing / non-working drivers. A USB device can be
identified by looking on five fields (as far as I know): device ID, vendor
ID, class code, subclass code, protocol ID. Hey, we're lucky, if we map
the protocol ID to the PCI field "programming interface", we are able to
include all USB device drivers in the PCI driver list. But, wait, it's
possible that we encounter a PCI device whose fields are equal to those
of a USB device. It would be wrong to load the appropriate USB device
driver. So we need an additional list for USB devices. But there are also
other bus drivers, i. e. Firewire. Let's make a new list for Firewire
devices. See the problem? In my opinion, it's a bad idea to "hardcode" all
these list types in CDI "headers". So we need a generic list at least, we
need to add a field for the bus type. Then every element of the list has
to contain a pointer to a bus-specific structure, for PCI its elements
would be "vendor ID, device ID, base class, subclass, programming
interface", for USB those elements would be named "vendor ID, device ID,
class ID, subclass ID, protocol ID" and so on.

But I still don't like this idea a lot... Don't know why. Maybe it's my
opinion that every driver should be "self-explaining" without "help"
from the Common Driver _Interface_ itself. My idea would be a new
section in each CDI driver where information about its supported devices
is stored. The list proposed by you would be created on every startup by
scanning all available drivers or on every build of the OS. Yeah, it's
the same list but it's created "on the fly", without help of CDI itself.
The problem is of course that this would be slower than your proposal,
but I think it to be more beautiful. :D

Oh, I nearly forgot: What's about operating systems without full CDI
support or such that don't need all CDI drivers? They need to remove all
drivers from the list which they don't use. Hence they are unable to keep
their list "in sync" with the CDI repository because they have to add
every driver manually to their private list. "My" proposal (or at least
brainstorming) wouldn't have that problem because drivers being not
available aren't added to the list of drivers. You could also add drivers
to the OS while it's running just by doing the scan again (or simply
adding a new driver to the internal list as if it was found during a
complete scan). I think it would be hard to complete the list proposed by
you while the system is running (or we need a "hack", a basic list with
all drivers available at startup and a dynamically growing list with all
drivers added on runtime).