--Apple-Mail-39--520480651
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


On Sep 22, 2004, at 4:55 PM, Bill Studenmund wrote:

> 	3) What do we want to do about overlapping wedges? The patch
> 	   currently doesn't permit them, which makes a lot of sense
> 	   at first glance - we want any block on the disk to be opened
> 	   by only one wedge at a time. However there's the MBR format.
> 	   It quite happily makes recursing partition entries.
>
> 	   If each MBR partition were its own wedge, then it'd be
> 	   trivial to have partitioning tools deal with extended
> 	   partitions. We just create a wedge for the extended partition
> 	   then sick the tools on that wedge. Then make an extended
> 	   partition in there, and repeat. This behavior might also
> 	   help import things like FreeBSD slices.

No problem.  Overlapping is only disallowed on a given parent.  So, to 
do what you're suggesting, a wedge would be the parent of the recursive 
wedges, not the actual disk, therefore no overlap would actually occur.

That said, right now wedges can't be parents of other wedges.  That was 
a conscious decision on my part.  Maybe we can revisit that late :-)

>
> 	   The problems though are: a) we now have wedge overlap, and
> 	   b) I'm not really sure how one would name the MBR wedges.
> 	   Only partitioning tools would really care about them.

Your partitioning tools still have to know they're creating "extended" 
partitions, because it needs to set the MBR partition type correctly.  
You also kind of want some way to tell a wedge "go explore for more 
wedges" or not, based on the parent wedge's partition type.  I don't 
think it's a good thing to willy-nilly go explore for sub-wedges every 
time.

> Hmmmm... Maybe the thing to do is add the concept of parent and child
> wedges. Add a list (TAILQ?) head and entry point to struct 
> dkwedge_softc.

There would be no need for that.  There's a reason that a wedge is 
presented to the kernel as "just another disk" :-)  If I chose to allow 
it, it could simply use the same discovery mechanism that all other 
disk drivers use.

> The one remaining issue I can see is that we would thus not make a 
> wedge
> for a Disklabel partition that is outside the NetBSD MBR space. However
> all the times I've seen us want to do that, we are bringing some other
> partition (like an msdos or Linux one) into the NetBSD partitioning
> scheme. Since we now can find the other partition natively, I think 
> we're
> fine.

See, now it's tricky... in the "BSD disklabel inside MBR partition" 
case, the block numbers in the BSD disklabel are absolute, not 
MBR-partition-relative.  So you'd have to search up the tree to figure 
out how to create those.  I haven't thought of a good way to handle 
this yet.

         -- Jason R. Thorpe <thorpej@shagadelic.org>


--Apple-Mail-39--520480651
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBUhTQOpVKkaBm8XkRAgNwAKCATMD5XAXc24FdZ+03LPGDzhAS8wCcDeTT
TYDDEbssTOJ+lS/6sWTJW5s=
=yA8e
-----END PGP SIGNATURE-----

--Apple-Mail-39--520480651--