[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> > 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*.
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: