Messages in this thread |  | | | Date | Mon, 29 Nov 1999 14:40:44 +0100 (CET) | | From | Jochen Dolze <> | | Subject | Re: Putting PCI-class/vendor/deviceinfo into source of PCI-drivers |
| |
On Mon, 29 Nov 1999, Magnus Damm wrote:
> > Any comments to that? > I think stuff like that should be outside the kernel.
Ok, but to have three additional lines in the (pci-only) drivers wouldn't blast the whole driver-area.
> Some kind of PCI detection script with a HUGE database.
I don't agree that we need a huge database (for what?). If a driver's available for that pci-device ('lspci -n') the driver itself should know it!!
I don't want to know which device it is, i only want to know, if there's a driver for it in /usr/src/linux/drivers - without the effort to know exactly the brand or something else. Start with the information provided with 'lspci -n' and you'll see how hard it is to get info if the device is supported. Sometimes the 'plain numbers' are written in the documentation, but often not!
If you think about a huge database, someone must take care of it. I think information provided by the PCI-Chipset should be good enough to decide such things as mentioned above...
> People came to some conclusion in the 'Hot PCI bus plugging" thread. > I think non-swappable PCI devices should be treated as a subset of the > swappable ones. > To add new hardware ID:s to the driver and recompile would > sure work for you. And for me. I would do the same thing. > But in the long run I think we must have some central database.
Why? Isn't /etc/pci.ids just such a database?
> But how will compiled-in drivers work if you need a userspace database?
No, you must think of two ways:
1. Uncompiled source
Now you can run 'the script', and this script is doing internally 'lspci -n'. After that it goes through the drivers-dir hunting for sourcecode which meets the class/vendor/device-id (grepping MODULE_PCIVENDOR,MODULE_PCIDEVICE and MODULE_PCICLASS). Then such a script can make a config. after making the kernel it should contain all pci-drivers which the kernel supports...
2. Precompiled modules as binaries
E.g. a distributor makes ALL modules and use a modified modinfo-program to determine from the module.o for what device it is and therefore install it into /lib/modules, if it meets 'lspci -n'...
> Maybe could people run some hardware detection script which generates > some header files for the kernel... Or? > Am I way off?
Is it now clearer?
Ciao
Joe_D
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |