Subject: device ID <->device name database [was hardware detection]
To: NetBSD kernel list <tech-kern@NetBSD.org>
From: Thierry Laronde <firstname.lastname@example.org>
Date: 09/27/2004 22:39:14
Some months ago (it was in March), I asked some questions about a way
to achieve some automatic deployment of nodes following this scheme:
1) A small NetBSD system (I call it DiagnOS) is booted on the target;
2) DiagnOS collects informations about the target and sends the
description to a remote Matrix;
3) the Matrix parses the file, creates a CONFIG
compiles an ad hoc kernel with a defined system for higher level
installation (software/logical usage of the node), put everything on a tftp/whatever server
and update the DHCP server config and instructs DiagnOS to reboot;
4) target node reboots and retrieve the new system, and software
After having worked a lot on a huge beast (the BSD version of the GIS
GRASS: KerGIS), I come back again to the schema sketched since I want to
be able to install efficiently things and to ease maintenance by keeping
a handful of files describing a node allowing for automatic reinstall
in case of desaster.
I put aside the network stuff, and took some simple steps first (this is
prototyping since, as discussed before, I think a part of the work
belongs to the `monitor' [an enhanced "firmware"]).
There is an actual way of doing things that mainly works.
Since in DiagnOS I don't want to drive but only to recognize devices,
the kernel is created by adding all the buses and `knots' i.e.
interconnection devices (bridges and so on): I want to be able to
traverse the tree without needing to go on the leaves.
DiagnOS needs only one thing: to have one way to communicate with
outside. So for the moment I use the serial console.
The config is simply the INSTALL_TINY with the buses, bridges (all
flavors) set, and the final devices commented out.
I add ISA PnP just for fun (may be less fun in case machine hangs...).
The kernel is configured with `md' as root fs but I don't use it
(it gives the opportunity to specify another root fs or halt/reboot):
-> Question? Is there some reason why the same choice is not given
with another type of root fs (say wd*) leading to a panic if init
is not found? [this is not a criticism, this is just a question ;)]
On the other side of the serial link, I don't use anything fancy:
just `tip', scripting the session to have the dmesg sent by DiagnOS.
Then comes the parsing of all the informations print by the autoconf
There is nothing insurmountable but before `sed'ding and `awk'ing
all around I'd like to have advices about the following:
1) I can go from top to bottom following the `config' path:
sys/conf/files gives all the informations needed to connect a device
name with the implementation files. From this, for example for PCI, I
can extract the Vendor ID and Device ID using <device_name>_product_desc
-> Question: are there exceptions, files not following this style?
Are PCMCIA etc. following the same scheme?
2) And last but not least: has this kind of stuff (going back from the
devices id to the CONFIG) already be done? Does the database already
Thanks for any comment.
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.org/ | http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C