Subject: Re: Another changer, another changer problem
To: NetBSD-current Discussion List <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 10/08/1998 00:15:15
[ 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 <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>