Subject: new disklabels - part2
To: None <firstname.lastname@example.org>
From: Leo Weppelman <email@example.com>
Date: 09/17/1999 21:24:34
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
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.