[ On Tue, October 6, 1998 at 00:35:20 (-0400), der Mouse wrote: ]
> Subject: Re: Another changer, another changer problem
>
> > [...longish rehash of the problems Greg Woods has with the "foo* at
> > bar?" style autoconfig...]
> 
> > 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.
> 
> This is simply false.  I can give you three reasons offhand: (1) it
> makes for very large cfdata[], pv[], and loc[] arrays; (2) lots of
> people don't like it (for whatever reasons); (3) it requires either
> something like devfs or an absolutely enormous devices directory.

I think you're taking the numbers too far here.

> (About (3), consider.  I see 10 "scsibus* at" lines in
> i386/conf/GENERIC.  Four of the places scsibusses attach are wildcarded
> "at pci"  Four more are wildcarded "at eisa".  There's a wildcarded "at
> pcmcia" and another "at isapnp", and 11 more that are single-instance
> controller lines.  If we assume each of the wildcarded lines is limited
> to only 4 instances, this gives us 16+16+4+4+11=51 places a scsibus can
> attach.

Don't go that far.  I presume that everyone would like to see the
current layering in SCSI maintained.  That means that it's merely a
matter of ensuring that there be a predictable way to map SCSI
controllers onto "scsibus" attachments.  Eg. slot # for PCI or Sbus
(I'll leave PCs out of this for sake of a clean argument!  ;-)

I.e. the first one found in slot order goes to scsibus0, the second to
scsibus1, etc.  We can then map the "scsibusN" to "cN" in /dev/*disk.
Each "cN" is given a different major number, and a given kernel
configuration is allowed only a maximum number of scsibus attachments
through a config line such as "pseudo-device scsibus N".  This same
number is given to MAKEDEV (perhaps as scsibusN).

(Pure ISA pc's could assign by order of IRQ or port# or whatever, though
I don't know what I'd do about PCI+ISA etc.  I don't like thinking about
PC hardware too much....)

> Each scsibus can hold at least 56 devices (120 if it's wide).

That's still just over half the possible minor numbers (2760) used for a
given bus, even if you assume expansion of MAXPARTITIONS to the current
MAXMAXPARTITIONS of 22 (plus one for the "raw disk").

Assume a "GENERIC" kernel has "pseudo-device scsibus 4" and you still
only need 11040 entried in each of /dev/dsk and /dev/rdsk.  I don't have
any problem with that at all, though a devfs would probably speed
installation up a lot!

Of course /dev/rmt et al will only need c4*d15*u8*(rewind+no), or a
total of 480 entries.

It would be nice to see CD-ROMs and all other random-access block
oriented SCSI devices accessible through the same /dev/*dsk/* entries,
too....

> > 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.
> 
> Decision makers?  You mean the people who write code?  Like the users?
> 
> When can we expect you to have a sample implementation ready for people
> to play with?

I for one wouldn't even dream of beginning such invasive changes to
NetBSD without some confirmation that there's some chance the result
would make it into the main stream code base.

The only alternative is to fork off another *BSD, and I currently can't
quite afford the luxury of doing this on my own either.  It's one thing
to write lots of e-mail messages on the subject of radical changes, but
quite another to pull one's foot out of his mouth and put his money in
their instead!  ;-)

The same argument probably applies for moving towards devfs, generic
disklabel support, unified major-number assignment, better kernfs
integration, and any number of other fairly low level architectural
changes.

Although I don't see any consensus forming here yet I don't know if the
NetBSD core group would be easily swayed by even a large group of users
that wanted to go in some "radical" direction such as this.

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