Subject: Re: new disklabels - part2
To: Leo Weppelman <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 09/20/1999 12:48:53
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
> 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
> - '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. :-)