Subject: Proposal about disklabels
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Reinoud Zandijk <firstname.lastname@example.org>
Date: 12/15/2005 13:09:38
Content-Type: text/plain; charset=us-ascii
On Thu, Dec 15, 2005 at 03:31:19AM -0500, der Mouse wrote:
> > Why should a disk device driver CARE if there is a label on the disk
> > or not?
> So it can report the status up the call stack, of course.
> That is, it shouldn't care, but in the current architecture (which
> makes disk labels the responsibility of the disk drivers) it must. Or
> else all the upper layers that deal with disk labels must not care
> either (and thus not care about getting the status), which strikes me
> as fragile.
That was my idea too Mouse.
A clean way to solve this problem for once and for all would be to :
* Move all disklabel stuff out of the device drivers completely. For what
its used for, range checking mainly and open/closed info, they can request
the information from the dkwedge implementation.
* Let dkwedge detect various disklabel `dialects' and compat code. This
compat code then adds the partitions as wedges to the disk's list as
normal. If no partition scheme is detected, all is considered one big
* Each disklabeling `compat' code could be made optional.
* When a filesystem type is not returned by a `compat' code, dkwedge could
probe all filingsystems using a new VFSOP for advice on mountability and
allow the filingsystems to add additional wedges. An iso9660 FS could then
add all mountpoints on all tracks it detects its markers on. UDF could do
This could also be implemented as dkwedge's partition code eliminating the
VFSOP and reducing complexity even more.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
-----END PGP SIGNATURE-----