DragonFly kernel List (threaded) for 2007-09
DragonFly BSD
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

From: Sascha Wildner <saw@xxxxxxxxx>
Date: Thu, 27 Sep 2007 18:12:38 +0200

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.



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]