On Thu 19 Aug 1999, Chris G. Demetriou wrote:
> Leo Weppelman <leo@wau.mis.ah.nl> writes:
> > So what I would like to do is:
> >     - move getmaxpartitions.[c3] to libc through cvscopy
> >     - apply the attached diff which does:
> >         - fix getdiskbyname()
> >         - extend the d_partitions field of the disklabel to MAXMAXPARTITIONS
> >           entries.
> >         - bump the shlib version of libutil to 6.0
> >         - move the getmaxpartitions() prototype from util.h to disktab.h
> 
> This, especially extending d_partitions, will likely cause problems
> for a lot of ports that use the disklabel struct to describe their
> on-disk labels.
> 
> e.g. from the i386 port:
> [ .... ]
> 
> Note the "*dlp = *lp" -- that's going to clobber a lot more than it
> used to -- including memory outside the sector that's been read -- if
> you expand the size of the disklabel.
> 
> Similarly, the readdisklabel code isn't going to initialize a whole
> disklabel from the bits it reads off disk (or will read memory it
> doesn't have access to).  This may cause leakage of somewhat-sensitive
> information from the kernel, or may cause the system to crash, or...
> 
> Also, ports have to be adjusted to sanity check the number of
> partitions claimed in the disklabel vs. the actual value of
> MAXPARTITIONS.
> 
> This is made more complex because of the issues around in-core and
> on-disk disklabels.  e.g. you want 'mbrlabel' to be able to use all
> MAXMAXPARTITIONS for its faked-up in-core labels, but you don't want
> more than MAXPARTITIONS partitions to be written out to an on-disk
> label.
> 
> Finally, since we're truly decoupling the size of the disklabel struct
> from MAXPARTITIONS, and saying that 'struct disklabel' no longer
> fits in the places that it used to be stuck, why not go further and
> bump MAXMAXPARTITIONS up to something larger, e.g. 64?  ("who'd want
> more than 64 partitions on a disk?"  8-)

Maybe a better approach is decoupling the kernel-disklabel from the
userland-disklabel? What I mean is:
    - export a disklabel definition to userland with 64 partitions
    - provide functions in the kernel to copy between the kernel and
      userland definitions.

This way, each port can choose it's own upgrade path towards more
partitions without going through this mess again (until we hit 64 or
whatever limit is decided here).
To be clear: This still requires the getmaxpartitions() use, since it
doesn't make sense to pass 40 partitions to a kernel supporting only 8
of them.

[ backward compatibility required as COMPAT_14? ]
> Uh, no, we don't want to, as far as i'm concerned we have to.  8-)

I thought so too, I was hoping someone came with the 'better method' ;-)

> I think you're going in the right direction, but you're still closer
> to the start of the journey than the end.  8-)

Yes, the problem has more to it than one expects on first sight ;-) 

Leo.