--qjNfmADvan18RZcF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 22, 2004 at 05:11:59PM -0700, Jason Thorpe wrote:
>=20
> On Sep 22, 2004, at 4:55 PM, Bill Studenmund wrote:
>=20
> >	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.
>=20
> No problem.  Overlapping is only disallowed on a given parent.  So, to=20
> do what you're suggesting, a wedge would be the parent of the recursive=
=20
> wedges, not the actual disk, therefore no overlap would actually occur.
>=20
> That said, right now wedges can't be parents of other wedges.  That was=
=20
> a conscious decision on my part.  Maybe we can revisit that late :-)

Ok. We can revisit this later. However we don't seem to have a way to=20
prevent simultaneous access to both parent and child wedges. But we can=20
add that when we add wedge paternity.

> >	   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.
>=20
> Your partitioning tools still have to know they're creating "extended"=20
> partitions, because it needs to set the MBR partition type correctly. =20

Agreed.

> You also kind of want some way to tell a wedge "go explore for more=20
> wedges" or not, based on the parent wedge's partition type.  I don't=20
> think it's a good thing to willy-nilly go explore for sub-wedges every=20
> time.

Oh, my thought would be that whatever created the wedge for the extended=20
partition would, just after creating the wedge, trigger the recursive=20
exploration.

So we only go exploring under controlled circumstances.

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

Oh, the lists were more for preventing opening both a wedge and its=20
children. When we go to open a partition, we look to see if any of its=20
children or their children are open and also look to see if a parent is=20
open.

> >The one remaining issue I can see is that we would thus not make a=20
> >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=20
> >we're
> >fine.
>=20
> See, now it's tricky... in the "BSD disklabel inside MBR partition"=20
> case, the block numbers in the BSD disklabel are absolute, not=20
> MBR-partition-relative.  So you'd have to search up the tree to figure=20
> out how to create those.  I haven't thought of a good way to handle=20
> this yet.

Oh, I thought wedges had a starting offset which was relative to the=20
underlying device. And then wedges short-circuited to the underlying=20
device (so that nesting partitions didn't end up nesting io processing).=20
So all the offsets of a child-wedge would both be 1) absolute in the=20
underlying device and 2) within the parent wedge. So BSD dislabel=20
partitions could just directly become wedges (within the NetBSD MBR=20
partition). MBR partitions would need a little help in that they are=20
relative to the parent partition, so partitions in an extended partition=20
would need to have its offset added in. But that shouldn't be hard.

Of course then this raises the question of what to do on really-old-style=
=20
BSD layouts where partitions g & h overlapped d, e, and f...

Take care,

Bill

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

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

iD8DBQFBUwTNWz+3JHUci9cRAsM4AJ9JS8aFrJ/R1qaczU013otpPfsUuwCfdbvD
EJmJnWjyRKpfvCBes1aAwz0=
=RzAS
-----END PGP SIGNATURE-----

--qjNfmADvan18RZcF--