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

[Kevin Wolf <kevin@xxxxxxxxxx>]

On Wed, Dec 30, 2009 at 05:28:57PM +0100, Max Reitz wrote:
> Kevin Wolf wrote:
> 
> >[...]
> >However, there is also a harder part. Let's forget PCI for a while now,
> >it's not a CDI driver (might be a future project, too). USB looks much
> >more like the generic case. And imagine a microkernel approach where
> >each CDI driver runs in its own process. Who is responsible for the
> >drivers (probably the driver providing the bus?), what information does
> >it need (list of all available drivers and their list of supported
> >bus_addrs) and where can it get the information from?
> 
> If I understand you correctly, that question has already been answered by
> my CDI.usb proposal. There's a function called
> cdi_usb_register_device_pattern() which does what its name says: A USB
> device driver calls it to tell the OS: "Hey, I'm a USB driver and I'm to
> handle that kind of USB devices." The OS has its cdi_usb_device_init()
> function which is called whenever a USB device is found (by a USB HC
> driver or by a USB hub driver), this one calls a function to enumerate
> that device. The enumerating process delivers the device's class id,
> subclass id, protocol id, vendor id and device id to the OS (just by
> filling those fields in the device structure).

Well, yes. This is what I described as the easy part. Your function is
obviously not the generic thing that we're looking for (as the usb in
its name indicates), but in the end you generate a cdi_bus_addr here.
Fine.

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

> If
> there's none available it should store the device in a list which is in
> turn scanned every time a new USB device driver appears by calling
> cdi_usb_register_device_pattern().
> Just look at the structure called "cdi_usb_device_pattern" if you want to
> know what information is needed about the USB device drivers.

I'll probably need to do that. Sounds like it could be made more generic
instead of being limited to USB. Or maybe it's not even needed any more
with the recent changes?

> >The last question
> >is probably the most interesting one: We need the table for all
> >installed drivers, but the drivers are not yet running. So this is
> >something that cannot be hidden in the CDI library.
> 
> As I said that's no problem with the current proposal. If a driver is not
> running when its device is found, the device structure is stored in a list
> until that driver registers itself.

It's a good point that needs to be considered but yet another unrelated
discussion. ;-)

> 
> >[...]
> 
> In my opinion the greatest problem is to share that list of drivers and
> devices between all USB bus drivers and USB device drivers - that's of
> course no problem in a monolithic kernel, but using a microkernel... You
> can't even simply do SHM, because the device and driver structures contain
> pointers to other drivers and devices which are not in that SHM area.

cdi_bus_addr must not contain pointers then. I think this is a
reasonable restriction. Doing the actual IPC would be something internal
to the CDI implementation anyway.

Kevin