[ On Wed, October 7, 1998 at 11:20:19 (+0930), Brett Lymn wrote: ]
> Subject: Re: Another changer, another changer problem
>
> > It
> >would be more practical when we have a boot time method for changing IRQ,
> >IO, DMA, dev, etc....
> 
> With the rider that this can make the system slightly more frail.

I suppose that depends on your definition of frail and how well the
implementors deal with the unexpected.

> A build on the fly system is convenient when you are adding/removing
> devices but there is a large scope for screwing up.  It can also,
> paradoxically, tie the kernel to the hardware more tightly than we
> already have.  For an educational exercise, try installing Solaris2 on
> a SS5 and then try booting that disk on a SS20.  The machines have the
> same architecture but Solaris2 will not boot - all the dev links are
> stuffed and boot -r will not fix it because it does not have enough
> information to find the disks to reconfigure.

Whoa!  We're definitely not talking about the way Solaris does it!
(except perhaps as a fundamentally flawed example)

The FreeBSD run-time device configuration system is merely a way of
over-riding the probe information between the time the probes are done
and the devices are attached.  I'm not certain it currently offers a way
to wire down device devices in the way we're talking about, but that's
an obvious extension of the mechanism.

The current FreeBSD implementation simply invokes the appropriate
configuration user interface if the static config file is not in the
root directory, or if the kernel is given a specific boot option (-C?).
The kernel.config file is updated by the re-configuration reboot.

The only way this could be considered "frail" is if you accidentally
delete the kernel.config file and then try a remote reboot, or if you
accidentally give a the wrong boot option remotely and can't interact
with the user interface.  This can be handled by using a timeout, though
it may have bad effects if the auto-probe order gets things all mucked
up for run-time.

Of course if you're running decent hardware where you can give the the
PROM some idea of where the console should point, and assuming you're
using a physical console attachment for reboots (as one concerned about
system frailty would presumably do) [eg. a hard-wired tty connected to a
terminal server], then you'll be OK regardless because your shutdown
command will tell the PROM where you're rebooting from and you can
presumably correct things like a missing kernel.config file by
re-creating it from your local notes about the system.

This is, of course, all blue-sky dreaming at the moment (though I will
note that there are existing systems where a reboot will redirect the
console to the user's current tty).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>