> [...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.
(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.  Each scsibus can hold at least 56 devices (120 if it's wide).
Multiply by 23 (22 partitions plus the raw disk device) and we've got
56*51*22=62832 entries in /dev/dsk/ just for SCSI devices, with an
equal number in /dev/rdsk/.  (This doesn't overflow our current 22-bit
minor device number size, but it comes uncomfortably close.)  And you
can't leave out any of those without either screwing someone who has
lots of a single card or un-wiring something...or skipping device
entries for something, which will screw you when you add the card or
whatever that those entries correspond to.  It also means that people
who like sdN numbering have to live with a system having sd44 and sd266
and sd1494, not sd0 and sd1 and sd2.)

All of these are fixable with sufficient effort.  Except for devfs
addressing (3), I don't recall seeing you propose any solution to any
of them, except for handwaving that amounts to "it's a SMOP".  Maybe
you're right and it *is* just that, but I for one will need to see code
to be convinced of it.  See below.

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

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B