[Marco d'Itri] > Petter, this is not a problem but a feature. Oh. I didn't realise. Thanks for clearing that up.
> Actually I consider discover broken by design because it needs a > proprietary database which must be updated for each driver added to > the kernel and for each new device supported by each driver. What do you mean by proprietary database here? I've never seen the work prorprietary used on a database like the one distributed with discover before. > There is a small number of devices which have two different drivers, > and they do because one of them is broken (or even both are, for > different hardware flavours). You should consider this a kernel bug. > I think there is a very small number of these devices in 2.6 > kernels, which can be easily be blacklisted even in the default > install. I definitely welcome more input on this. My point is that as a distribution packager, it is important to be able to work around such problems. It does not really matter to me if I consider it a kernel bug, a hotplug bug, a discover bug, or attribute it to the general eval world. I need a way to fix the problem. > Hardware detection in linux in the future will be more and more tied > to kernel drivers, look also at the pci:* and usb:* aliases in > /lib/modules/2.6.4/modules.alias, which in the future will allow to > semplify a lot the hotplug scripts (and as you can see do not even > support having two drivers for the same device). Sounds good. I wrote a little script to import the kernel hw mapping into the discover database. It would be nice when this is no longer needed, as Ian indicated might happen soon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
