>Data point: the mac68k port uses MacOS partitioning, and puts one NetBSD
>filesystem per partition. We don't have a traditional unix disklabel.

This is probably the best way.  You have to support the native
partitioning, and mixing native partitioning with BSD partitioning makes
things complicated.

>Idea: I've been thinking about increasing the # of partitions too. As I
>understand it, the amiga port already has gone to 16 partitions! So the
>problem of kernel code supporting #partitions != 8 has been dealt with.
>
>As I understand it, the one problem (which is large) is that the kernel's
>idea of # partitions and /dev's idea MUST match, or else you loose BIG
>TIME. So kernels from before the change won't work after, and ones from
>after won't work with non-updated systems. A royal mess!

No, the kernel's MAXPARTITIONS just needs to be larger than d_npartitions
in the physical label, and it may be important not to expand existing
labels.  This works because dkcksum() only checks up to the last
partition given by d_npartition.  Partitions with numbers d_npartitions+1
up to MAXPARTITIONS-1 are garbage.  A comment in disklabel.h even suggests
that the code is supposed to use the struct hack to support any number
of partitions, but the code doesn't actually do this.  It has too many
`sizeof(struct disklabel)'s.

>Oh, the max # of partitions is 22. You can have mre than that, but then a
>disklabel won't fit into a 512 byte block (from somewhere in the disklabel
>headers).

Larger numbers should probably be made to work if the sector size is
larger than DEV_BSIZE.

Bruce