Re: PCI hardware detection [RFC]
On Fri, Jul 20, 2001 at 08:13:19AM +1000, Glenn wrote:
> On Thu, 19 Jul 2001 14:30:41 +0200
> "Thierry Laronde" <thierry@cri74.org> wrote:
>
> > Hello,
> >
> > Just a summary of the principles I plan to use for, at least, my own stuff
> > and that can be of some use for others too.
> >
> > The following will focus on the Linux kernel, but since the installation can
> > be independant from the OS installed, the use of a Linux kernel for other
> > system installations is not forbidden ;)
> >
>
> A while back i made a program that compared a table of pci id's (obtained using libpci (from pciutils)) to kernel modules. http://cvs.debian.org/debian-installer/tools/pcidetect/
>
> It worked for PCI network devices, but i didnt fill in the database for other devices.
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...).
> >
> > In fact the entries in /proc/bus/pci/xx/ are the more complete (these are
> > the headers) and the right place to look for information.
> >
>
> It does make sense to get the pci information directly from /proc rather than probing directly, libpci can do either (compile option), so its probably easier to use it rather than making up your own /proc parsing code.
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.
>
> > Database in user space
> > ----------------------
> >
> > Bootstrapping the installation
> > ------------------------------
> >
> > For my own purpose, I will mainly use network installations. The process
> > is the following but in fact can be applied for other devices (not only
> > NIC ones) :
> >
> I think detecting storage devices is just as important, unless we assume all storage drivers are installed from the start.
> hmm, i guess we can fetch storage drivers to ramdisk prior to inserting them, and it wouldnt take much extra memory, i would like to be able to install to lowmem machines (4MB).
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...
> > existing OS
> Best to scan /proc/partitions to identify existing partitions, determining existence of other OS's may be painfull though.
Yes, but I made the assumption that there were nothing in /proc for this
since there is, at the moment, perhaps not all the drivers that allow you to
have the information about the partitionning.
>
> > - send this info to a service that takes the "decision" about
> > partitionning and packages to install
> > -> this step can be thought in conjunction with FAI
> If we use parted we could try to resize existing partitions to make room for a new partition which we can use, or create a loopfs on an existing partition, then we can have heaps of space to store packages, or base.tgz.
>
> The catch is if installing locally we need somewhere to store partitioning software prior to partitioning, if we store it on an existing partition then it makes partitioning more complex (cant repartition over our temp space). We have to assume the boot medium is read only.
>
> ramfs (or ramdisk) is the simplest solution, but its best we be very carefull about what we put in ramfs so as not to increase minimum memory requirements.
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 simpler
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.
>
> Also David did kdetect, which (if i remember ocrrectly) uses both libpci and libisa (if thats the right name) to handle isa cards too, even though pci has been standard there are still lots of 10Mbit isa network cards still around, so ISA is something we have to consider as well.
>
I will look at all of this.
Cheers,
--
Thierry LARONDE, Centre de Ressources Informatiques, Archamps - France
http://www.cri74.org/
Reply to: