On Oct 5,  9:02pm, Greg A. Woods wrote:
} [ On Mon, October 5, 1998 at 12:01:48 (-0700), Bill Studenmund wrote: ]
} 
} > Do it the way we can now! :-) Hard-wire it in the kernel. Map only the
} > ones which exist. If a drive has one LUN, hook up one LUN. If a drive has
} > 8 LUN's, hook up 8. :-) 
} 
} Ah, OK, I guess I should've known that....
} 
} However that's where I lose my enthusiasm for BSD's autoconfiguration
} code.  It's really cool in an experimental or developmental environment,
} but as soon as you take it into the real world you'll find yourself
} building a new kernel for every connector you connect and every switch
} you toggle and every jumper you join.  It's one thing to say "well, just
} wire everything down in your config" and quite another to actually live
} with that decision.

     You have total flexibility as to what degree you wire everything
down.

} This is in fact one of the reasons why commercial users don't like using
} some BSDs in production environments.  They want their "operators" to be
} able to attach new devices just as they can (in theory, or at least the
} vendors make them think they can) with most commercial unixes.  They
} don't want to have to call in the systems programmers to build new
} kernels every time they have to add more disks, etc.

     Is this mythical operator also going to <optionally low level
format>, partition, mount, <optionally load data>, and update config
files (i.e. /etc/fstab).  If they're going to do all this, then
they're probably capable of building a kernel, if needed, as well.  If
not, then the systems programmer is going to have to be involved
anyways.  Your argument doesn't have any credibility.

     Besides, BSD is nothing compared to what would happen if you were
to try to move disks around at random on an HP-UX system (yeah, yeah,
I know you don't think much of HP-UX; but it is one of the top five
workstation OS'es).

} There are 4095 major numbers and 4095 minor numbers per major number for 
} us to play around with (at least these days with dev_t == u_int32_t).

     I don't know where you're getting these numbers.  In NetBSD
1.3.2, the current shipping version, the major/minor split is 8/8 for
a range of 256/256, and in -current it is 12/20 for a range of
4096/1,048,096.

} There's simply no reason *not* to wire everything down from the get go, 
} *especially* with SCSI, and probably even with PCI.

     Except for the fact that it would mean making major changes to
the system.

} Now there is a "minor" architectural change necessary to upset the bus 
} cart and give every scsibus its own major number, but it shouldn't 
} really be that hard to do.

     Major numbers are assigned to device drivers not buses.  This is
not a "minor" architectural change.

} Perhaps NetBSD really does need a boot-time machanism like FreeBSD's
} boot configuration tool with the primary goal of allowing one to wire 
} down devices after they've been probed.  This way folks could change a

     This sounds like a potential disaster waiting to happen, and not
particularly useful.  Are you going to have to enter the options
everytime you boot?  What happens if the machine panics and reboots if
you're not there?  If you don't re-enter it everytime then where is
the info stored?  And, how do you modify it?  What happens if the info
gets corrupted?  Personally, I don't think this is something that
would be particularly useful in a production environment.

     The main place where this would be useful is with ISA devices
where you can't easily probe for the resources they use (there was a
patch floating around at one point for the i386 that did this).  It's
not necessary on *real* machines where you can easily probe for
devices and the resources they use.

} motherboard and reconfig the same "GENERIC" kernel.  Of course there's

     You do keep a GENERIC kernel on your root disk, don't you?  You
could just boot with that, and build a new custom kernel.  Of course,
if you wire down the devices and not the controllers, then you
wouldn't have to build a new kernel; although, you may have to swap a
couple of cables (or controllers) to get your SCSI chains to appear at
the right places.

} else and build a new kernel first.  Almost everyone I know who does use
} FreeBSD in production has chosen it over NetBSD because of features like
} this.

     I doubt it.  The more likely reasons would be their greater
emphasis on things like performance (new VM system, merged buffer
cache, and possibly faster TCP/IP), greater device support (including
some RAID adapters), and concentration on ease of use features (i.e.
better install, gui style sysadmin tools, etc.).  Of course, NetBSD is
also working on some of these problems.  NetBSD 1.4 should be very
interesting.  I can hardly wait.

}-- End of excerpt from Greg A. Woods