Re: hardware detection using libpcid
Joey Hess wrote:
>
> 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.
>
My mind is stuck in a loop trying to working out hardware detection,
retrievers, a shell, and core components.
The boot disk will have at least one working retriever on it.
To setup a different retriever we need to
1) fetch/install a shell if we dont already have one, to enable
postinst(and other things) to work.
2) fetch/install hardware detection
3) possibly fetch/install new kernel modules ?
4) fetch/install the new fetch method
It would be good to be able to remove the dependency on a shell so it
was optional (non-core) rather than a requirement (core).
Can we fetch/install a shell as a normal package if we dont already have
a shell ?
Looks like it would take some big changes to avoid having a shell as
core.
> > 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:
>
> CONFIG_PCI_NAMES
> 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*.
>
I would think a libdetect based hardware detection program would result
in the same savings, its list is seperate as well as far as i know.
Reply to: