--T4sUOijqQbZv57TR
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 
wedge.

* 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.

Thoughts?
Reinoud

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ6Fc+4KcNwBDyKpoAQI/Lwf/aWjv7yqRQG1n4cyiPipZ2+i6EiJHZOIC
khW3dzWPGd36NPOx9faK9PxjuOh7nKfcUTg1MJ9Tsilhm8k4Q/lP3NBkK52fz/PV
JN82uxtZhk2jA8iih6+QynS5tLeCPV2eKWfbms5J1hUgPu65WzCWg86KFK8PV4G2
CXWTIAGt7mpaFCRU1XwYGMAf5bdqO+N9DtkItDplWT6cU3t3Uh53aRg98l96kpWM
CmHzdoTJEkNVzKqF8HPi26QJRzL6XCso7hGUcLHNuzazFLmdB9IQZaKWQdUBOJoV
xmYSpwipnLB8HyPkmJR/e44qmshc51sXGMqnxq500vB4F5nwxXQ1Zg==
=Dn2N
-----END PGP SIGNATURE-----

--T4sUOijqQbZv57TR--