DragonFly kernel List (threaded) for 2007-09
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: RFC: nuke pcidevs and usbdevs
Thomas E. Spanjaard wrote:
Hasso Tepper wrote:
- Remove the usbdevs and pcidevs files. If the code wants to use defines
for vendor and/or device id's, it has to define them itself.
Con. Imho, it's better to keep things like these in one place, for
easier maintenance and collision-spotting. The problem is we didn't
really inherit pcidevs from FreeBSD, but added it later on, making lots
of drivers ill-adjusted, or not adjusted at all, to pcidevs.
pcidevs sounds like a good idea, The Right Thing etc. when one first
looks at it, but...
* Companies like to change names, assign the same product name to
different product IDs, etc.
* Even the BSDs using pcidevs.h (Open, Net) can't agree on using the
same names for the same IDs as I've seen when I was converting some
network drivers to use pcidevs.h.
* To properly identify many devices you have to look at chip revision
info and several other things anyway, some of which seem hard to
formalize in pcidevs.h.
So pcidevs.h just adds ambiguity but gains little actual value, if you
don't count "having all in one central place" as a value in itself which
it is not if that is all you get.
So personally, I'm for hardcoding the IDs in the drivers. Since the
descriptions are also hardcoded, it shouldn't really confuse someone
reading the code to find out what ID is which device.
I'm also against printing info about unattached devices in dmesg. Why
would we want it? There's pciconf(8). Of course the info is from
upstream. But I'm actually quite happy with not having to maintain a
"complete" PCI ID list ourselves.
Sascha
--
http://yoyodyne.ath.cx
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]