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

[Matthew Iselin <matthew@xxxxxxxxxxxxxx>]

On Sun, Jan 3, 2010 at 8:33 PM, Kevin Wolf <kevin@xxxxxxxxxx> wrote:
> 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.

Right, leaving the method for list generation up to the implementation
is an easy way to get out of that tough problem ;)

Seriously though, this is a good idea, as it gives the implementor
significantly more power over the format of the data in this list (and
therefore can implement their hotplug handling in the most effective
manner for that OS, using the data in their own format).

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

I understand.

I think we are reaching the stage where we need to now determine a
proper interface and define the requirements of the OS in order to
support this kind of behaviour. In other words, take the results of
this discussion and turn them into a proper design for the feature. Up
to you though, if you feel more discussion is necessary, then by all
means, let us discuss this further. :)

Cheers,
Matt