Subject: Re: Another changer, another changer problem
To: None <current-users@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: current-users
Date: 10/01/1998 23:57:12
[ On Fri, October 2, 1998 at 11:42:26 (+0930), Brett Lymn wrote: ]
> Subject: Re: Another changer, another changer problem
> 
> As others have stated, you can nail these devices in the config.  The
> abc tool I released for testing last week will actually
> _automatically_ nail any disks that are present for you.

Cool.  Where's that at?

> >Another thing is that if we have a limit of 8 bits for the minor
> >number, there can be only 32 nailed-down devices.
> >
> 
> with current technologies, this appears to be a reasonable
> limitation...

Well, if you include the maximum number of LUNs, that's only one SCSI
bus worth of devices....

> The ability to rescan a bus for new devices is a nice feature but with
> the note that some buses cope with new attachments more gracefully
> than others - scsi in particular can be a major PITA if you screw up
> the bus termination/connections when adding a new device "live".

Adding new devices isn't the first order issue -- dealing with devices
that were properly connected, but powered down, is my first concern.

> find and configure or just find?  If it is just find then you may want
> to look at the prtconf tool that I bundled with abc which tells you
> what devices the NetBSD kernel knows about.  The prtconf tool is
> really just a sub-function of abc.  Both prtconf and abc share the
> device detection code, prtconf just prints out what was found whereas
> abc does a bit more than that :-)

In general the System V way of doing things was to have the kernel
always prepared for anything you could throw at it -- i.e. full run-time
configuration, at least for things like SCSI.  They generally tried to
avoid having to rebuild kernels and reboot.  Only where that couldn't be
done, such as with PC bus interrupt configuration, etc., was tuning
and rebooting necessary.  (AT&T had a variant of SysVr4 running on their
big 3B2/4000 fault tolerant system which could re-configure even CPUs on
the fly.  Unix does run their telco switches!)

I'm speaking in past tense since I'm remembering SysVr3 and SysVr4 on
things like 3b2's and ISA/EISA based i386's, etc.  Amiga SysVr4 was a
bit different again, as was NEC's VME-based 68k port and Pyramid's
various ports, but I don't remember all the details.  Oddly enought the
first official Sparc port of SysVr4.0 wasn't done by Sun either and it
was very much in line with the original 3B2 release, and zillions of
miles different from today's SunOS-5, aka Solaris-2.

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