> > To avoid this and to be able to create automatic kernel configs, one
> > solution could be to add more module info into the source of pci-capable
> > drivers (e.g. 3c59x.c from Donald Becker):
> >
> > MODULE_PCICLASS("0200");
> > MODULE_PCIVENDOR("10b7");
> > MODULE_PCIDEVICE("5900,5950,5951,5952,5900,9000,9001,9005,9055");
> >
> > Then scripts could look for a driver class "0200" (Ethernet controller)
> > from vendor "10b7" (3Com) which supports the cards shown in PCIDEVICE
> >
> > If there are two or three (or more) Vendors with same chips (like
> > in the Tulip-driver) the vendor string can look like this:
> >
> > MODULE_PCIVENDOR("1011,11ad,10d9");
> >
> > Any comments to that?
>
> I'm preparing a very similar mechanism for my PCI hotplug code. It should
> work this way:
>
> o Each driver contains a list of supported vendor+device pairs (likely
> a more general ID's, so that they can be used for ISAPnP, PCMCIA and
> CardBus as well).
> o Depmod extracts these data and stores them in modules.dep.
> o If a new device gets inserted, the kernel looks up its ID in all currently
> loaded drivers and asks them if they want to handle the device.
> o If no driver is found and kmod is enabled, modprobe gets called to find
> a driver corresponding to the device ID according to modules.dep and load
> the appropriate module.
>
> Maybe a similar mechanism could be used for USB as well.
I do not think it is so easy: usb devices have identification, but
they also have classes and alternate settings.
Pavel
-- I'm really pavel@ucw.cz. Look at http://195.113.31.123/~pavel. Pavel Hi! I'm a .signature virus! Copy me into your ~/.signature, please!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/