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/12/1998 20:58:45
[ 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
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 <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>