You guys may not want to go in this direction, and I have not really
thought it out very far, but ... when I put in "struct device" and
"struct dkdevice" and such, I intended for a "dkdevice" to have a
bottom-level "disk" driver that just handled "get sectors" and "put
sectors" operations (along with "first open" and "last close" and
such as needed of course).

A next-level-up "generic" driver would handle labels, partitions,
and so on.  Normal (super)user-code access to any disk (e.g.,
"mount") would go through the generic code, hence would see the
label.  There would be an "even raw-er" partition (in the generic
code, presumably) that short-circuits down to the real driver.

Aside from bootstrapping problems, this might allow the entire
label (and real volume-management) code to happen in user mode.
The "real volume-management" aspect would mean that if you take a
big removable drive (e.g., Jaz) with an ordinary file system that
mounts on /foo, remove the media, put in another one that normally
mounts on /bar, the user-level management code could read the
label, figure out that the drive goes on /bar, and Do The Right
Thing.  This manager stuff would use the "very raw" partition
and handle complicated stuff like building an in-core label from
data scattered all over the drive.

The bootstrapping problems are the killer here -- I have no idea
how to handle them.

Chris