On Fri, 17 Sep 1999, Leo Weppelman wrote:

> It has taken me a while, but here is the next episode in the disklabel
> update saga. I think I covered the items mentioned in the various
> discussions. 
> 
> The items below were written with the following guidelines in mind:
>   - It should be possible to use a generic-disklabel in both kernel and
>     userland. It should have a 'large' number of partitions. All ports have
>     the _same_ definition of the generic-disklabel.
>   - The kernel will be able to convert (at least) the port's native
>     disklabel from the native to the generic label format (to allow
>     finding the root partition). This is the current situation.
>   - There is no necessity for the kernel to support conversion of
>     generic labels to some native format. This is probably better left
>     to labeltype specific programs (like mbrlabel).
>   - There should be COMPAT_1x support of the current userland disklabels.
>   - Historical behaviour in keeping state of 'internal' disklabels is
>     retained (stickyness).
> 
> The following items are more aimed at the specification/implementation. There
> are still question marks at some places...
> 
>   * The basis of the generic-label is the current dislabel definition
>     (as defined in 'include/disklabel.h'). The additions are:
>       - 52 (2*26 == [a-zA-Z]) partitions (MAX_GENERIC_PARTITIONS)

I'd vote for 64 partitions, and shoving the "whole disk" one at #63. For
now, ports could keep shoving a "whole disk" partition at #2 or #3 (c or
d).

>       - 'sticky' member.
>       - 'labeltype' (UNKNOWN/MBR/AHDI/RDB)
> 
>   * The generic label will be the label stored in dk_label and thus is
>     the `in-core' label. This allows the virtual disk drivers to use
>     the new label format.
> 
>   * The semantics of kern.maxpartitions and (the should be kernel only)
>     define MAXPARTITIONS is: The maximum number of partitions allowed on
>     a _native_ disk.
>     Note: it might even make sense to make this device dependent. When the
>           kernel supports multiple label types. Or drop it alltogether.
> 
>   * Sticky labels
>     Labels are _not_ sticky by default. The in-core label will be dropped
>     on the last close of the disk device unless it's sticky. A label can
>     be made sticky by setting the 'sticky' member of the generic-disklabel
>     and activate the label by either a DIOCSDINFO or DIOCWDINFO ioctl. The
>     sticky-flag can be cleared in a simular way (usually DIOCSDINFO only).
>     The flag will also be dropped when a media change is detected.
> 
>   * When a device is opened, the kernel checks the label. If the kernel
>     recognizes the label _and_ there is no sticky label, the kernel will
>     update the in-core label.
> 
>   * setting the on-disk label
>     - When the argument of the ioctl is a generic-label that cannot be
>       converted -> fail [ what about errors??? ]
>     - Also update the in-core label & drop sticky bit.
>     - Does is make sense to allow the passing and updating of 'specific'
>       labels? My opinion is 'no', this better handled outside the kernel.
> 
>   * The ioctl-interface
>     - provide COMPAT_1x
>     - When only the generic label can be passed - keep it as it is 
>       (pass the structure).
>     - When also the various 'native' labels have to be passed to the
>       kernel, passing a structure with size/pointer/type and a following
>       copyin/copyout looks to be the better solution.

In principle, sounds good. :-)

Take care,

Bill