Re: hardware detection using libpci
Glenn McGrath wrote:
> Ive been thinking about hardware detection. I think hardware detection
> should be a dependency on the fetch method it applies to.
> e.g. the http/ftp/nfs retriever should depend on network and modem
> hardware detection.
> This way, if a network retriever is to be used, the hardware detection
> component of it should have already detected the relevent hardware and
> determined what kernel modules are needed to support it.
Yes, I agree. This means that hardware detection packages should detect
hardware in thsir postinst, if they fail, the postinst should fail. Thus
until hardware is detected, stuff that depends on it will not install.
> Its good points;
> 1) its small, looks like that with libdetect the hardware list is a
> significant proportion os its total size, ive just ignore things like
> the cards name, just care about the card PCI id and the kernel module
> that it needs. Focusing on detecting the hardware required for specific
> kernel modules, rather than detcting evberything and then mapping it to
> kernel modules should make it more modular and smaller.
> 2) libpci is from pci-utilities, its fairly portable, can either use
> /proc to get pci ids or probe hardware directly, the later making it
> portable to other OS's
Another advantage (I may have said this before) is:
By default, the kernel contains a database of all known PCI device
names to make the information in /proc/pci, /proc/ioports and
similar files comprehensible to the user. This database increases
size of the kernel image by about 80KB, but it gets freed after the
system boots up, so it doesn't take up kernel memory. Anyway, if you
are building an installation floppy or kernel for an embedded system
where kernel image size really matters, you can disable this feature
and you'll get device ID numbers instead of names.
An 80k win on the kernel side is *amazing*.
What I really worry about is maintainability. Someone has to keep these big
lists of PCI ids that you have generated up to date. I don't expect they will
change often, if at all, but new ones will always need to be added. It would
be really good if the numbers could just be pulled out of the kernel source
somehow (it does contain the same information, right?).
see shy jo