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

[Kevin Wolf <kevin@xxxxxxxxxx>]

On Sun, Jan 03, 2010 at 10:27:53AM +1000, Matthew Iselin wrote:
> On Sun, Jan 3, 2010 at 9:38 AM, Kevin Wolf <kevin@xxxxxxxxxx> wrote:
> > On Sun, Jan 03, 2010 at 09:23:30AM +1000, Matthew Iselin wrote:
> >> A simple <your scripting language here> script could be added and
> >> called to update the list during the build of CDI.
> >
> > Actually I think C would be the right tool. Link all object files in the whole
> > tree together and add a small main() function that enumerates all the drivers
> > in it. All the parsing is done by the compiler.
> 
> Hm, good point. A little more complicated, but also comes with the
> bonus of needing no new dependency on Perl or Python or <your
> scripting language here>.

Hm, I was just missing that driver enumeration is OS specific. So with
this approach we wouldn't be able to share the tool (unless you want to
compile everything twice: once for the OS and once with a different
cdi-osdep.h for the generation of this list). I'm not even sure that all
OSes want to have the list in the same format, so probably it's better
anyway if we only describe how you can do it and leave it to the CDI
implementations.

> > Actually, I think's quite boring. Some cdi_provide_device(struct
> > cdi_bus_addr*), a function for removing (probably takes the cdi_bus_addr
> > again?) and we're done.
> 
> Right, this is kind of what I was thinking of when I considered the
> feedback given to the original proposal.
> 
> The question is: can a USB device be fully... explained, I guess, in a
> cdi_bus_addr? What about Firewire? Max raises an excellent point in
> his mail; I don't understand cdi_bus_addr enough yet to comment on
> whether or not it suffices for these purposes. If a cdi_bus_addr
> struct can describe the wider range of potential devices (and
> therefore drivers), this will not be a problem.

It's the same question as asking if a USB device state can be fully
explained in a cdi_device. Consider it a base class, so the USB module
would extend it, of course. This is why my table consists of pointers
instead of directly putting the data there - it's not a static size.

Kevin