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

Re: PCI hardware detection [RFC]

On Thu, 19 Jul 2001 17:00:41 +0200
"Thierry Laronde" <thierry@cri74.org> wrote:

> I'm trying to write a "general purpose" script to build a general database
> from the Linux kernel sources. But there will be some particular problems
> (exemple: when the *_pci_tbl is put in a file "main.c" and that one must try
> to find the name of the object file the module will have...).

It may be more trouble than its worth, it is a tendious job to go through
the kernel source by hand yes, but at least that way you know you are
going to get every case, and ive done the network drivers (but they havent
been tested).

> I must definitively give a look at libpci (since it seems to already make
> what I'd like my tool to make). The problem is as always to have the
> lightest possible tool.
libpci is pretty small, the 18kB i mention for pcidetect is with libpci
built in statically.

> Same here. 4MB is my target (8MB easy, but I want to be able to handle
> smaller memory). In fact, one driver is important : the one that allows you
> to retrieve the others. For network installs, since you have the correct
> driver in initrd, you can access the network, that is "everything", and you
> can use a small tool on the machine to take the devices detected, to match
> it against a "remote" DB, and to retrieve the modules needed for access to
> other hardware. The luxe being to have a tool that sends the basic detection
> to a "server" that sends back the module to retrieve etc...

Still, network install is a bit of a convenience, lots of people will want
to install from CD, hdd or initially from a pile of floppies

You need to make sure that you have one working retriever, which includes
not only the kernel module, but also the configuration programs to enable

Net retriever will obviously require different support programs than an
IDE, SCSI or floppy based retriever

> Yes, but we can see this with a "bootstrapping" procedure : first, in
> ramdisk, a small utility that detects partitions and is able to modify the
> partitionning (resize is far more complex, so we can start with a simple
> case). And, as always, the access to supplementary data (network, local
> storage --- CD) allows to have the tools, without putting this twice in
> memory : once for the stockage (ramdisk), the other for the running process.

Partition detection, resizing tools can be retrieved if we are using net
or floppy retriever,
Net config tools can be retrieved if we are using net of floppy retriever,
So i think that it is important for the end user to be able to customise
the boot/root disk acording to their needs.


Reply to: