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

[Max Reitz <max@xxxxxxxxxx>]

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). The OS then looks after a
registered USB device driver which is able to handle that device. 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.

But all that just in case I understood you correctly. If you were "just"
talking about sharing those information between the different drivers
(aka "processes" in a microkernel ;-)), see my statement below.

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

> [...]

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.