Re: hardware detection using libpci
> Splitting detection up like this seems to me to be the most space
> efficient way of doing it as well.
> Yesterday i started hacking together a small program that uses libpci to
> detect the required ethernet kernel modules, it is attached.
I spent some time on a similar program that uses lib detect It can be
found at (still alpha, meant to generate discussion):
I'm not trying to compete here, just presenting what I have:
My approach is similar, I have a tiny utility that converts the list
of known hardware from the format that lib detect uses (a *.lst file)
into a header file. My program (ddetect) includes said header file.
ddetect makes calls into libdetect (which itself uses libisapnp
internally). I got it to link with uC-ulibc (though the udeb at the
url above links with glibc) and it was ~55k (staticily linked), 10k of
which was the header file (could be smaller if I was clever like Genn
and left out the card names :-) )
My vision was to get 'ddetect' (my first name wa 'dethfind', that
didn't last long), libdetect, and libisapnp to play well with uC-libc.
This would allow us to have a tiny general hardware detection tool.
libdetect is very close to playing well with uC-libc, isapnp I haven't
This method's limitations:
1. I believe lib detect is fairly linux-centric.
2. To get libdetect small I had to remove gettext support. That's easy
to do but then two versions of libdetect are floating around on Debian
> Its limitations;
> 1) It only detectes hardware for the following modules, 3c59x.o rtl8139,
> ne2k-pci. Its fairly simple to add support for other modules, just a
> matter of doing it, no thinking involved.
> 2) Its obviously limited to PCI devices, seperate programs will have to
> be used for ISAPNP, PCMCIA etc
This methods good points:
1. libdetect can detect a whole lot of hardware (pci, mouse, modem,
joystick etc.) and is modular so we can keep things build with it
2. easy to update the list of hardware we know about as the info is
taken right out of the *.lst files.
> 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
I like the way Glenn includes only the bare minimum of necessary
information to detect and start using the hardware. His comments
about how the dependancies should work are right on the mark.