Hello,

Since my questions deal primarily with bootstrapping procedures and
hardware detection, I thought this list was the best one. Please direct
me elsewhere if I'm mistaken and sorry for the noise. [note: no need to
cc me on replies since I'm subscribed to the list for several months
now].

To summarize: I sketched a project, and made a prototype for allowing
"plug and use" of machines on a network.

The procedure is as follow:

1) The "new" machine is connected to the network and the bootloader 
asks a DHCP server for its elements ;

2) The DHCP server sends to an unknown machine the elements
to download the `DiagnOS' which is a kernel + a rootfs to analyze 
the machine hardware ;

3) The bootloader downloads via tftp the elements and launches DiagnOS ;

4) Some programs analyzes the hardware and, using a TCP/IP client,
communicates to a TCP/IP server running on the vulcan a text description
of the machine. 

5) The vulcan builds a custom kernel and rootfs, and builds a boot menu
for the new machine (proposing several choices : running the OS built,
downloading a "ghost" like system (say g4u...) etc.) ;

6) The client machines receives the instruction to reboot ;

7) Client machine reboots and downloads its custom menu ;

8) If this is the first time the OS is launched, further customizations
are possible.

Sometime ago, I have made a prototype with some limitations and the
following combination of software :

1) I have taken into account only ethernet based TCP/IP, and worked with
PCI cards ;

2) The bootloader is a combination of GNU GRUB + the drivers borrowed
from Etherboot. GRUB was compiled with all the PCI ethernet drivers and
was instructed to ask for its menu via the network ;

3) The client machines were boot from floppy with only GRUB on the
floppy ;

4) GRUB retrieves the elements (BOOTP + tftp) ;

5) The kernel was a Linux 2.2 one with a bunch of ethernet drivers 
built in (since I need only one way to access mass data, and it was via
the network).
The rootfs held some scripts which were mainly using Linux /proc 
(misnamed) to retrieve info for the CPU, the amount of memory, the PCI 
ids. The whole informations (text form) were then passed to the vulcan
(build machine) via a simple TCP/IP client ;

6) On the vulcan, some scripts parsed the elements, matching the PCI ids
with drivers using a database built using some scripts I wrote (at the 
time, there was not such a thing in Linux 2.2; these appeared 
progressively in Linux 2.4). Indeed, another kernel was not compiled,
but the scripts populated a rootf with the correct drivers. The custom
menu (for GRUB) was written too and the client machine was informed to
reboot ;

7) The rest as described.

This was a prototype and this mainly worked. But for a more robust
solution and a more maintainable one I needed to add some features to
the bootloader (GRUB). By the time, I have contributed some code to GRUB
to make it usable in El Torito emulation and on special floppy format
(up to 1743ko) and reworked stage1 (used both on MBR and on first sector
of the partition). My diagnostic was that we had to start other almost
from scratch. Since the initial model for GRUB was the BSD bootloader I
have started to look to *BSD and found that what I thought would be
correct to implement (for example in the organization of the code) had
already been made more than 10 years ago. So... I'm here and learning.

Since I still want to implement this but on a BSD base, I'd like to
have advices (I'm a beginner with the BSD kernel, but I have the docs
--- The Design and Implementation..., and so on).

So my questions:

1) What are the limits people want to put on the bootloader? The natural
tendancy is (for GRUB and others) to add more and more feature but this
will simply make the bootloader another kernel. But the ability to list
the hardware, access ressources via the network are useful one, since
this will allow to use machines with small memories, when a kernel with
a bunch of useless drivers will be unable to fit in this very memory.

2) Even if the MI part is relatively small for a bootloader, do you
think there is a sensible way to provide a uniform interface between
distinct architectures? Are the "problems" encountered on i386 more
easily solved on other platforms, and are there parts that I described
above that make not sense on not i386 architectures? 

3) The Etherboot drivers are derived from the Linux ones, and are late
relatively to these ones. GRUB is itself late relatively to Etherboot
from which it takes the ethernet drivers and every update is a problem.

Do you think there could be a correct way to derive (as is partially
made AFAIK) the stand version from the current ones, using the ukphy as
a PHY? The main advantages being that the two version, stand ones and
current ones could be "automatically" keep in sync. But is it relatively
reasonable to think that this is achievable?

4) Is there already a kind of database matching hardware identifiers
with NetBSD drivers, for PCI and others?

Please note that I'm not claiming that something will appear in a couple
of weeks. I'm already engaged with a fork of GRASS, a GIS software,
since I have derived a BSD version from the last public domain release
of GRASS from the CERL (the fork came from the fact that we disagree
with the directions taken with the GPL GRASS). This is not vaporware
(the first tarball will appear on april the 15th) but this is an
important beast (no more a huge one, since I have made dramatic
cleanings; but the code base is large).

But since KerGIS (the name of this GRASS derived work) will be used to
create custom applications, running on handheld or workstations, in some
years able to be use in grid computing (raster analyzing, image
processing and so on), I'm interested in the ease of deployment so I may
devote some time and I need to invest the small amount I have on the
correct tracks, so your advices are more than welcome.

Thanks for any tip.
-- 
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C