Subject: device ID <->device name database [was hardware detection]
To: NetBSD kernel list <tech-kern@NetBSD.org>
From: Thierry Laronde <tlaronde@polynum.com>
List: tech-kern
Date: 09/27/2004 22:39:14
Hello,

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
installation begins.

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
framework. 
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
structs;

	-> 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
exist?

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