Re: hardware detection using libpci
David Whedon wrote:
> >
> > 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):
> http://www.gordian.com/users/davidw/debian.html
>
> I'm not trying to compete here, just presenting what I have:
>
Cool
> 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 :-) )
>
I guess the card names are handy for the user if all doesnt go to plan,
i just left them out because the program didnt _need_ them, and they
take the most space.
>From the three modules i looked at there appears to be a few pci ids
that arent in libdetects list, so maybe a kernel module based list would
be more complete.
> 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.
>
Even better would be to have a bunch of seperate detection programs that
could still work together fair easily. We dont want code duplication,
but we still want to be able to easily strip out stuff thats not needed
or wanted.
> libdetect is very close to playing well with uC-libc, isapnp I haven't
> looked into.
>
I havent tried libpci against uclibc, would be a good thing to do
though.
> This method's limitations:
> 1. I believe lib detect is fairly linux-centric.
I noticed that libdetect uses /proc to get the pci ids, it cant do
hardware probes to get the ids. Whilst Joey has said that we wouldnt
ever ship a kernel without /proc support, i think that having the option
to do without /proc is a good thing, if we want to make it easy for
users to build a disk with there own kernel then its best is we depend
on as few kernel features as possible.
> 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
> systems.
>
Maybe the upstream author would incorporate your changes, if not then i
guess it will get confusing, but if we need to modify libdetect to make
it more modular (or other big changes) then i guess we may need our own
version anyway.
> 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
> small.
>
Ive never had much luck with mouse detection with various programs,
depending on my bios setting my machine sometimes locks up. I guess
thats why it needs to be modular, to take out the risky stuff.
Is it much effort to make it modular ?
> 2. easy to update the list of hardware we know about as the info is
> taken right out of the *.lst files.
>
This is a good point, if we use a program that has just had a new list
created then it may be less reliable than a list that has been out and
about for over a year.
Glenn
Reply to: