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

[Kevin Wolf <kevin@xxxxxxxxxx>]

On Wed, Dec 30, 2009 at 12:29:50PM -0600, Rich Edelman wrote:
> 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.

We're two at least.

> > 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).

Sounds more or less like the classic monolithic kernel.

> 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.

I think we're getting really close to it with CDI. Current
implementations lack two things:

a) The unhandled list. This is what Max already mentioned in one of his
   posts. It's probably not CDI's business, you can do it transparently
   in your implementation of the CDI library without any special
   interface to the drivers.

b) The database of all installed drivers. I think this is what Matt's
   proposal is going to make possible.

For a monolithic kernel, that's it. In tyndur, we'll need some more
communication behind the scenes, but at the moment I don't see any
additional requirements to the interface.

Kevin