[ On Sun, October 11, 1998 at 01:00:48 (-0700), John Nemeth wrote: ]
> Subject: Re: Another changer, another changer problem
>
> On Oct 5,  9:02pm, Greg A. Woods wrote:
> } [ On Mon, October 5, 1998 at 12:01:48 (-0700), Bill Studenmund wrote: ]
> } 
> } 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.

Having talked to some commercial users who don't want to use NetBSD, I
think I can say that I know what I'm talking about.

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

OK, so I missed 8 bits.  12 was already enough so I didn't go looking
for more.  I guess that's what happens when you're in a hurry and the
line just happens to be the last one on your screen.  Are you trying to
state my case for me here?  ;-)

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

Huh?  It woudn't necessarily be visible unless you're writing device
drivers, let alone purvasive.  How do you count that as "major"?????

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

I think I suggested making buses like SCSI into pseudo-devices.

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

Why don't you boot up FreeBSD, install it on a spare machine, and try
out all your scenarios?  My own risk analysis for the purpose I
suggested it for show that it would be an acceptable solution.

I like other solutions better, but this is certainly a short-term option
that eliminates many problems with the current situation where there's
no real solution at all.

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

I'm not actually talking about using this mechanism for adjusting the
probe results (i.e. what FreeBSD does), but rather for pre-wiring the
device assignments.  I fully agree that the FreeBSD purpose for such a
mechanism is only required on "flaky" hardware.
 
> } 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.). [....]

Well, again, I think I do know what I'm talking about....


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