Re: RFC: discover 1 -> 2 transition plan for Debian
[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.
Reply to: