[ On Mon, October 5, 1998 at 12:01:48 (-0700), Bill Studenmund wrote: ]
> Subject: Re: Another changer, another changer problem
>
> I agree that it'd have been nice if the raw disk weren't 'c' (and
> especially not 'd'). You do realize that the partition table isn't looked
> at for RAW_PART, don't you? Partition RAW_PART will ALWAYS give you the
> full disk.

Of course I do.  That's the problem I've been trying to avoid.  I want
to rename RAW_PART to RAW_DEV.  The raw disk should not be a "partition".

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

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.

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).
There's simply no reason *not* to wire everything down from the get go,
*especially* with SCSI, and probably even with PCI.

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.

> Right now our scsi layer does two things. It only uses unit numbers for
> found devices, not potential devices (i.e. you don't encode the target/LUN
> in the unit field of the minor number) AND we dynamically scan for things.

If you use your "namespace" appropriately you can dynamically scan for
things *and* have them wired down firmly at the same time.

> As far as I know, it's possible on EVERY NetBSD platform, if you take the
> time to wire things down in your kernel. Every device driver should
> support both wildcard and wired-down locators, and should indicate that
> the wired-down one is preferable. If a device driver doesn't, send a pr.

I guess I'd not really figured that much out about PCI yet -- for some
unknown reason I somehow expected that it wasn't driven by the physical
slot position.  Maybe that's just because of my bad experiences with
most PC motherboards.  If you move from motherboard to motherboard
without paying enough attention it often seems as if the PCI "dev"
number is purely random and magic.

However this begs the questiong of what someone who's stuck with
multiple types of motherboards is to do if there's nobody around to
build custom kernels for each and every one of them.

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
motherboard and reconfig the same "GENERIC" kernel.  Of course there's
still the guessing game of figuring out which Adaptec controller is
which if you've got the same number of disks on each bus, but at least
you can immediately reboot and reconfig without having to go somewhere
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.

The FreeBSD folks have a couple of minor wiggles to iron out and then
they'll be able to assign major numbers from a common table and then
they can have a data driven MAKEDEV.  Of course they'll soon have a
fully functional devfs too, which will given them an even better fit in
commercial production environments.  I don't think it would take too
much time and effort do add these features to NetBSD either, but it will
take some forward movement by the decision makers around here.

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