On Fri 20 Aug 1999, Chris G. Demetriou wrote:
> Leo Weppelman <leo@wau.mis.ah.nl> writes:
> > Maybe a better approach is decoupling the kernel-disklabel from the
> > userland-disklabel?
> 
> That's close to what I think i suggested, but not quite as useful.

Yes, my suggestion is less than halfway of yours I think ;-) Please consider
it as an intermediate step. I don't think it is feasible (for me) to
take the entire step. That being said, I like the direction you are heading
at.

> > What I mean is:
> >     - export a disklabel definition to userland with 64 partitions
> 
> Sure...
> 
> >     - provide functions in the kernel to copy between the kernel and
> >       userland definitions.
> 
> uh, i don't think that's quite right.

If one of the function arguments is the valid number of partitions to
copy, those functions can:
   - provide the backward compat14 interface
   - pass 64 partitions (or some other number) to parts of the kernel
     that support this.

> for the most part, even in the kernel, you want to use the "large # of
> partitions" disklabel.  This is true at least because of the existence
> of (programs like) "mbrlabel" which manipulate the in-core label
> without the expectation that it'll ever be written back to disk.  For
> them, it can be valuable to provide more partitions throughout the MI
> code.

Definitely! I don't know "mbrlabel", but I can imagine that vnd-devices with
lots of partitions might come in handy... But since the vnd-driver also
uses dk_label (== struct disklabel), it is still limited by MAXPARTITIONS
unless a major kernel overhaul is performed.

> There's the minor hitch that not all of those partitions (the ones >
> MAXPARTITIONS) will be accessible on ports with small maxpartitions,
> but I think that's OK.  (At least people can know what they're
> missing.  8-)
> 
> The important thing to do, in my opinion, is decouple the on-disk
> format from the MI-kernel/userland format.  You have to do this
> anyway, because the MI kernel and userland needs to be able to
> represent many formats other than the native 'struct disklabel'
> format.  (MBRs, old sun disklabel, Mac and other partition tables,
> etc.)

I see what you want, but I think it is a step too far - at least for me it
is. It also has some semantic side effects. I mean, kern.maxpartitions
becomes useless. Does it represent:
    a) the number of partitions on any (pseudo)disk (== current meaning)
    b) the number of partitions on disks shared with the native
       OS
    c) ???

It is useful to carefully consider what the userland disklabel definition is
going to look like, so the userland transition on the ioctl-interface has
only to be done once. To support other disklabel formats, the best thing
todo seems to reserve a certain amount of slack in the structure and use
unions in the definition. So label formats can be squeezed in.

> A good start on the conversion functions (setdisklabel,
> checkdisklabel) are already there.

I don't know about checkdisklabel(), it looks like setdisklabel() does the
checking too ;-)

> > 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.
> 
> depends on what you mean by 'pass'.  The cost (time) of passing the
> functions into the kernel is pretty much irrelevant.  To a
> zeroth-order approximation, disklabels are never set or read by user
> programs.  8-)

I did not write this with 'cost' in mind. I was basically concerned about
userland dealing with a kernel with a different number of maxpartitions.

> getmaxpartitions() (and other good sanity checks) are still quite --
> perhaps more -- important so that programs like disklabel(8) can
> provide users better feedback about what they're doing wrong when
> creating disklabels for their systems.  Right now those sanity checks
> and diagnostics... aren't so great, in my opinion.

When various kernel subsystems are using a different number of partitions, it
might even make sense to put 'maxpartitions' in the MI-disklabel structure
or provide a separate ioctl to retrieve it. The importance on good sanity
checks increases indeed.

Leo.