Subject: Proposal about disklabels
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Reinoud Zandijk <>
List: tech-kern
Date: 12/15/2005 13:09:38
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hiya folks,

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 
the same.
This could also be implemented as dkwedge's partition code eliminating the 
VFSOP and reducing complexity even more.


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.6 (NetBSD)