On Fri, 13 Feb 2004, Allen Briggs wrote:

> On Fri, Feb 13, 2004 at 08:44:07AM -0600, Frederick Bruckman wrote:
>
> The main reason we never switched to 16 was that it is a flag day,
> meaning that if you update the kernel w/o updating userland, things
> will not work.  If you don't update your device files, you'll get
> strange results (what was wd1a is now wd0i).  If we're willing to
> deal with that, then we should go ahead and do it.

We could either

1) do as i386 did, and use the high bits for the new partitions. That
avoided the flag day, but folks are complaining now that that's ugly.

2) take the opportunity to redo the whole mapping, spacing the minor
numbers wide enough to accomodate the whole "Apple Partition Map", in
case the kernel ever catches up.

I think we should choose one of those before NetBSD 2.0.

> > When you factor in the
> > fact that most drives on NetBSD/mac68k hosts have HFS partitions too,
> > the current maximum of six useful partitions is very limiting. I think
> > we should follow the lead of i386 and other ports, and do what it
> > takes to permit up to sixteen. At the same time, we should stop hiding
> > the driver partitions, to make it easier to maintain the machine
> > entirely from within NetBSD.
>
> Well, if we expose the driver partitions, we can chew through 16 pretty
> quickly.  On my tibook with just Apple stuff, two HFS partitions, a shared
> APPLE_UFS partition and two NetBSD partitions, NetBSD is on the 12th
> partition.  If I recall correctly, FWB puts a few extras in there, too.
> But I could be misremembering...

I seem to remember reading that you can stuff something like 22 into
the kernel disklabel. So we could have 9 or 10 bits for the major, 6
or 7 bits for the minor, but only the first 22 would be recognized by
the kernel.

Frederick