From: Jason Thorpe <thorpej@nas.nasa.gov>
   Date: Sun, 04 Feb 1996 16:07:57 -0800
   
   On Sun, 4 Feb 96 13:48:57 PST 
    "Scott L. Burson" <gyro@zeta-soft.com> wrote:
   
    > Well, that's why there should be (and is) a separate sun4c kernel.
   
   BZZT.  Look at GENERIC ... it boots on the sun4 and sun4c.  A lot of 
   effort was put forth into making a "unified" 4/4c kernel, and that will 
   continue once the 4m support is integrated.

Excuse me -- I meant "... a separate kernel that swaps IDs 3 and 0".  I was a
little too telegraphic there.

   #
   # Support for the "SCSI weird" host adapter used with the Sun-4/110.
   #
   disk            sd0 at sw0 drive 000 flags 0
   disk            sd1 at sw0 drive 001 flags 0
   disk            sd2 at sw0 drive 010 flags 0
   disk            sd3 at sw0 drive 011 flags 0
   
   This is right out of the stock SunOS 4.1.3 GENERIC configuration.

Yow!  Well, it's been a long time; I forgot there was anything like that.

   For a volunteer port-master (i.e. all of us who are port-masters), it can 
   be a real headache to keep all of the kernel configs in sync.  For those 
   of us who have to ship kernels to the FTP server via slow 14.4k links, 
   it's a pain.  If your build machine is slow, it's a pain.
   
   On the other hand, having one GENERIC kernel that's going to find all of 
   your SCSI disks no matter where they're located is really nice.

I will accept that it's "really nice" for the people setting up the
distribution.  I can see that it would also be nice for existing NetBSD users
retrieving an updated kernel, provided they like to run with dynamic mappings
in general.  It remains unclear to me whether it's nice at all for someone
converting over from SunOS the first time.  My own experience is that it was
not particularly nice, and I hear reports that others have similar
experiences.  Please stop for a moment and let this in: not everyone likes
this feature!

I think that what NetBSD users must be doing is adapting their SCSI chains to
the dynamic mapping, by assigning disk IDs to correspond at least roughly to
the probability of the disk being removed from the system; thus the root,
`/usr', and other essential filesystems would be on drives with low IDs, and
filesystems with random junk in them (making it relatively likely that the
disk would get removed, or put on some other machine, or something) would have
higher IDs.  This minimizes the chance of having to make lots of changes to
`/etc/fstab' because a disk has been removed or added.

I can see how that might work well, but please understand that those of us in
SunOSland have had no reason to organize our disks that way!  Right now I boot
off sd0, have `/usr' on sd3, another filesystem on sd2, and sd1 is where I
plug in random disks.

At the *very* least, the installation instructions should encourage people to
renumber their disks with the most important ones getting the lowest IDs, so
that the dynamic mapping will be a feature and not a hassle.

One more comment and then I'll shut up; this issue is not important enough to
spend any more time and bandwidth on.  The needs and interests of new users
are not always the same as those of established users.  If you want NetBSD to
proliferate, it will help if you make the conversion process as painless as
possible.

			      The GENERIC SPARC kernel can boot/mountroot 
   from any drive + network.  Same with the hp300 GENERIC.  Same with the 
   sun3 GENERIC (I know - I have a sparc, sun3, and a bunch of hp300s at 
   home).  Other ports may differ for various reasons (like, gee, 
   it's really hard to figure out which drive you booted from because the 
   PROM doesn't tell you, etc.).

Well, as I say I'm out of date, so if this works now, great!  I do seem to
recall that it didn't work in 1.0, but my memory may be incorrect on that
point too.

-- Scott