Re: [cdi-devel] [PATCH 0/3] Rework device creation mechanism

[Rich Edelman <redelman@xxxxxxxxx>]

On Wed, Dec 30, 2009 at 11:39 AM, Max Reitz <max@xxxxxxxxxx> wrote:
> Kevin Wolf wrote:
>>>
>>> The OS then looks after a
>>> registered USB device driver which is able to handle that device.
>>
>> Registered means running here, right? If so, it doesn't use help any
>> further. What Matt is talking about is _launching_ the driver if it's
>> not running. We have a device 8086:100e, no running driver likes the
>> device and we need to find out that we should start e1000.
>
> Well, what do you mean with not running? Not even loaded? I don't know
> how you want to start a not loaded driver upon device detection. No

I think not even loaded is what Matt had originally intended, and what
Kevin was referring to as well.
It's certainly what I've been thinking all along so far, but perhaps
that's just me.

> problem in a monolithic kernel, of course - all drivers are "loaded"
> right from loading the kernel because they're all in the kernel. But a

I'd love to just have a minimal driver set compiled in to my kernel,
or perhaps loaded from an initrd of some sort,
and then dynamically load drivers for other devices as they are
detected (whether a hotplugged USB device or
an add-in PCI SATA card).

> driver needs to register itself somehow, be it active or passive. The
> current model for USB is active registering (call a function), but
> there's no problem about making it passive (store information in a new
> section or whatever about the devices to be handled). Anyway the OS
> must (just imo, of course ;-)) load the driver first to know which
> devices it's able to handle. The only "escape" would be to name the
> driver in a way the OS can search a driver by its name - i. e. call
> that e1000 driver "8086-100e". But that's imo stupid (sorry, I just
> say it in that way, because nobody except me suggested this model up
> to now *g*) because the name of a driver _in the filesystem_ is
> totally unrelated to CDI. So one must _load_ a driver before knowing
> which devices it is able to handle. And if you use a "passive"
> registration system, loading means registering. Hence, registered is
> not forced to mean running (just in the active model) but to mean
> loaded.

For quite a while I had planned on just using a native driver
architecture in QuokOS, but Matt and Kevin got me interested in CDI.
:)
I had planned on dynamically loading all drivers as they were needed,
except for a couple of base drivers that would always be compiled in
to the kernel.
Some of those drivers were: IDE driver, some filesystem drivers, cdrom
driver, a PCI bus driver. When I initialized the driver subsystem the
first thing it did
after internal initialization was to call the register functions of
the drivers that were compiled in. Those register functions did
nothing more than register the drivers with the appropriate driver
subsystem. The PCI bus driver would use a register_bus_driver()
function, while the a SATA driver would call
register_storage_driver().
Once all the compiled-in drivers were registered, the subsystem would
iterate through the list of bus drivers. Each bus driver would
enumerate the bus and call the init method on each driver in the list
until one of them returned true. At that point, the driver's "start"
method would be called, and the device would be handled. The init
method was passed information from the PCI header.. class code,
subclass code, vendor id, device id, so it could test against those
and do whatever else the driver needed to do to make sure it did
really support that device. If no drivers were found for the device,
the device was put on an "unhandled" list.

After all the appropriate compiled-in drivers were started, I'd be
able to iterate through the unhandled list and call a helper process
to locate and load any needed drivers. I had planned on having each
driver also provide a mapping file of which devices it supported. All
the driver mapping files would be added to an index file (likely a
sqlite database) that the helper process would query. This would allow
multiple drivers to be returned for a single device, perhaps even with
other metainfo about the driver itself. The helper process would then
be able to direct the kernel to load each driver in succession until
one was able to handle the device.

This also allowed drivers that returned false from the init method to
be unregistered and unloaded if you wanted.

In practice I've never actually implemented any of this, but it's how
I was planning on doing things. Also, I should note that each driver
was meant to run in it's own thread, whether that be kernel space or
userspace.

Now I've rambled on enough, especially for a first post to this list,
but I hope it at least gives some ideas!

Rich aka "quok"