On Tue, 14 Jul 1998, der Mouse wrote:

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

They are basically the same thing. The difference is how they interact
with complicated partition systems, such as extended DOS partitions. To an
extent, it is semantics.

> 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, but other than the dial-in/out flag for tty's, we don't use more than
the first 8 bits or so.

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

The above's why we haven't switched. Though I'm sure you're proficient
enough to navigate this change, the concern is that most people aren't.
Or that most people don't want to deal with this change, especialy in
production systems. You can get into problems that your backups don't
work, etc...

The idea is to tie the switch to using a new major number for a block
device. A device node with the old major number has 8 partitions, and a
device node with the new major number has 32 partitions. That way, the old
/dev still works even after the change. And the new dev does nothing with
the old kernel (it doesn't know about the new block devices). So rather
than hosing the wrong partition, if you boot a new kernel with old /dev,
you just get 8 partitions per disk.

Take care,

Bill