According to Chris Torek:
>
>	A. The first set includes devices that were not found.
>
>This is pretty obvious and could be used to configure a new kernel
>for the same machine, omitting unwanted device drivers. 

This is the idea - to allow the tailoring of a kernel to the machine
it was booted on.  On the basis of some conversations with new users
and from the -help mailing list it seems that a lot of people find the
config file a bit daunting.  From that I thought that if there was
something that could grab some information from the currently booted
kernel (presumably a generic one) and present this to the user as
"here are the devices you have in your system" and "here are the the
associated kernel parameters we can set for them".  By doing this an
optimal kernel for the given machine can be built in an interactive
manner - if the default values are chosen wisely then it may be a
matter of the user just accepting the defaults and getting a better,
leaner kernel for their efforts.

> On the other
>hand, if you are going for loadable drivers, and you load the driver
>to probe (if necessary) and then unload it if not found (or never
>load it if not needed to probe), this whole idea becomes uninteresting.
>

Yup :-)

>	B. The first set has wildcards; the second does not.
>
>These desires, whatever they may be, exist only in the mind of the
>guy who assembles the machines.
>

Correct - as I said above, the aim is not for a full autopilot but
just to automate the nitty-gritty stuff like assigning sd0 to always be
target 0 lun 0 on aha0, tying down the com ports, adding in the bus
mouse support, making sure the sb driver's drq is updated... these
sorts of things can be automated.  I know that having this sort of
tool will not suit everyone but rather to help out the newby users
with doing their own kernel configs without having to get their heads
around the config file at first - they can use the automated tool to
make the config file and then study it to see how their decisions were
translated into config-ese.

>Finally, if you just want the locators that were used to configure
>the kernel, well, those are in the config file used to configure
>the kernel! :-)
>

Well, that is true for the most part this argument does break down
with the wildcarded entries since they are not explicitly in the
config file :-)  and it can be these ones that can cause some grief.
If you pull a scsi drive off the bus on a kernel that uses wildcards
to assign your device id's then you can suddenly change all the disk
id's which upsets mount somewhat when the fstab no longer matches the
system config.  The disk need not even be part of the running system
it may be, for example, a ms-dos disk that never gets mounted by the
kernel - I was clunked by this one once upon a time.  By tying down
these wildcards you avoid this problem.  Admittedly the desire for
other locators is a bit more difficult to justify apart from the debug
value of the kernel telling you where it believes things are.

-- 
Brett Lymn, Computer Systems Administrator, AWA Defence Industries
===============================================================================
  "Upgrading your memory gives you MORE RAM!" - ad in MacWAREHOUSE catalogue.