[ On Wed, October 7, 1998 at 15:44:59 (-0700), Bill Studenmund wrote: ]
> Subject: Re: Another changer, another changer problem
>
> I think the main reason that you're getting so much resistance to this
> argument is that you've only wired the disks to a controller. If the
> controllers re-arange themselves, then you're just as hosed as you are if
> you add a disk and you're using sd*. Wiring disks to controllers is not
> really wiring them down.

I've been thinking about the controllers all along.  Remember when I
suggested that all disk and network controller drivers be put under some
generic layers similar to the way scsi controllers are all attached to
a scsibusN now?

After all that's what the "cN" in /dev/dsk/cNtNdNsN is all about.

If I can identify the controller by bus slot number or some combination
of jumpers and switches physically configuring it, then I should be able
to keep it in the same place regardless of what's inserted near, before,
under, or after it, etc..

> I doubt that making a scsibus take up a whole major number will ever
> happen. But some system which would be able to preserve device
> configuration between boots would be interesting. And with it, the disks
> could be wired down just as easily as the busses can. So sd2 could always
> be at controller 3 target 5, even if controller 2 gains 20 disks.

That path leads down to the rocky road Solaris and HP-UX et al are
already on now.....

Perhaps the idea of having an intermediate (i.e. post-probe, pre-attach)
run-time configuration facility is the best way to wire down the
location of devices in bdevsw/cdevsw without having to leave room for
everything right from the start.  This answers most of the concerns I
and everyone else has with fully dynamic configuration but without the
horrors of the solaris "boot -r" and such because you can manually go in
and re-wire all the device assignments at boot time without having to
customize another kernel.

I now agree the only other obvious way to do this in a truely portable
and scalable fashion is to build a virtual configuration space using
sparse tables (eg. linked lists or btrees instead of bdevsw, etc.) so
that every possible arrangement of hardware can be expressed in a single
namespace and to invent and to use a virtual filesystem ala devfs that
presents all of the hardware successufully probed in the system (and of
course can dynamically make new devices appear following run-time probes
so that I can remember to turn on my tape drive and not have to
completely reboot).  Doing this might be good in the long run because it
will make a far more scalable and manageable system, but it is a *lot*
of re-engineering....  (all my half-baked ideas to short-cut this
level of re-engineering seem to have fallen in defeat! ;-)

I think the FreeBSD folks are 90% of the way to having a completely
working devfs.  They only need a little configuration language (or some
sort of translucent filesystem layering) to describe the non-physical
attributes of device special files, such as permissions and ownerships,
etc.  They already have a runtime kernel configuration tool, albiet
oriented to slightly different goals than I'm thinking of....

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