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)
      - '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.

Leo.