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: "Sepherosa Ziehau" <sepherosa@xxxxxxxxx>
Date: Thu, 27 Sep 2007 22:14:13 +0800

On 9/27/07, Hasso Tepper <hasso@estpak.ee> wrote:
> These files have annoyed me quite some time. Maintaining entries in there
> is real pain. So I took some time to investigate how useful they are. From
> these files structures used for two different things (at least in theory)
> are generated:
> - to get "nice" defines to use in the code (pcidevs.h/usbdevs.h)
> - to get nice device descriptions in dmesg (pcidevs_data.h/usbdevs_data.h)
> To achieve both goals these files should contain as much devices as
> possible of course. But it's obvious that we don't have enough resources.
> Our *devs files are much more out of date than they are in other BSDs.
> There is several possibilities to improve the situation. We could use
> regular import from <random>BSD, we could use some automatic method etc.
> But is it needed at all? How much of this data is actually used?
> Only fraction of defines are actually used in the code (lets not look at
> generated _data.h files in this context). Some quirks use them of course,
> also drivers matching vendor and device id's. The second usage is
> questionable already IMHO - why to have define used in one place? Look at
> dev/usbmisc/uftdi/uftdi.c for example - I'd rather have there plain id's
> with proper documenting comments. So, the answer to is: "defines are
> rarely used".
> Nice device descriptions are not used at all at the moment. All nice
> descriptions about PCI devices you see in dmesg are coming from drivers
> (see bus/pci/pcisupport.c for example; yes, this is hell ugly as well),
> I don't see the pcidevs_data.h included anywhere in the code. The USB
> code doesn't include the usbdevs_data.h either - it's done only if
> USBVERBOSE is defined, but by accident I didn't move this out from
> usb_port.h during USB code cleanup. The point is - no one complained
> yet ;).
> There is more issues with nice descriptions for USB devices:
>  - Nobody has even close to complete database for USB devices. There is
>    just too many of them.
>  - If candidates for such databases exist, data in them is often wrong
>    do to rebranding, several devices using same id's etc etc.
>  - Often USB devices contain vendor and device _strings_ themselves
>    (see usbd_devinfo()).
> So, my proposal is:
>  - 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.
>  - As maintaining descriptions database makes sense only for PCI devices,
>    look at possibilities to generate structures for that from the
>    share/misc/pci_vendors file. If it's needed at all?
> Waiting for comments.

I am fine with defining PCI device ids in each driver, but I think we
should add a head file in sys/bus/pci that defines PCI vendor ids
(e.g. split vendor ids part out of pcidevs.h).

As about PCI devices' description, I don't think they worth the
trouble; they are just eyes candies.

Best Regards,

Live Free or Die

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