>>> It'd probably be easier to go to 16 partitions
>> That probably ought become the default for everything [...]
> The thing is that the minor number for devices is only 8 bits.  If
> you increase the number of partitions, then you decrease the number
> of drives a system can have.

Yeah.  When I said "it'd probably be easier to go to 16 partitions" I
was talking for the original questioner, not for NetBSD as a whole.

> The tricky part, in addition to finding extra space for the extra
> minor bits, is to somehow make it so that the old device nodes still
> work right.

> The decision on how to deal with this is to wait for NetBSD to
> support "slices."  At that point, the major number of the device will
> be changed, and the new major number will support 32 partitions per
> drive.

What, pray tell, are slices, and how would they help?  I've yet to hear
any description of them that doesn't sound like nothing but partitions
under a different name.

But that's semi-irrelevant, because someone (mycroft, I think it was)
already committed the following (excerpt from sys/sys/types.h in this
morning's sup, though it went in quite a while ago)

#define major(x)        ((int32_t)((((x) & 0x000fff00) >>  8)))
#define minor(x)        ((int32_t)((((x) & 0xfff00000) >> 12) | \
                                   (((x) & 0x000000ff) >>  0)))
#define makedev(x,y)    ((dev_t)((((x) <<  8) & 0x000fff00) | \
                                 (((y) << 12) & 0xfff00000) | \
                                 (((y) <<  0) & 0x000000ff)))

In short, we *already* have 32-bit dev_ts, with 20 bits of minor
number, and all existing device nodes continue to work Just Fine.  The
only cases that don't work are device nodes served by an NFS server
that imposes more restrictive limits, and if for any reason /dev has to
be shared with a legacy OS that has a different layout of the bits
within the dev_t.

Yes, switching an existing system to 16 partitions requires some
delicate tap-dancing in /dev.  Provided drive 0 holds /dev and enough
tools to fix it up, it can be done "live", without having to resort to
auxiliary boot media; I know, 'cause I've done it, back when I first
did the 16-partition changes for my sparc and sun3 machines.  Indeed,
you don't need to touch /dev at all, provided you're willing to have
userland say sd1e when it really would like to say sd0m, or sd5a
instead of sd2i, or sd2f when you want sd1f, etc.  But this breaks a
few tools, so you're better off in the long run rebuilding /dev.  And
you *can* go back, with similar caveats: an old kernel with a new /dev
will mostly work, provided you remember that /dev/sd0[i-p] really
access sd1[a-h], etc.

					der Mouse

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