Re: [PATCH] diskpart

[Roland McGrath]

> Ok, ch* on the root node changes all of the nodes and a ch* on any of
> the leaf nodes returns EROFS.  Reasonable?

Sounds ok to me.

> I started exploring it about two weeks ago; it is well written (wrt
> being os-independent).  Thus, I imagine that we could use that.

I am in favor of using (and fixing/enhancing) existing GNU facilities if
there are some, though I have not looked art Parted at all myself.

> We do detect logical partitions, however, having a tree structure does
> not make sense.  The primary partition table may have either 3 primary
> partitions and an extended partition or four primary partitions.
> An extended partition may contain either an extended partition and a
> logical partition or a logical partition.  Generally, extended
> partitions are unnamed.  Given this, what are you suggesting?

I wasn't really suggesting hierarchy for the "primary" vs "extended"
partitions of a PC partition table.  I meant more like, within each PC
partition (numbered as linux numbers them) look for tables in all formats
as if that partition were a whole disk.

> OpenBSD disklabels, unlike NetBSD and FreeBSD, contain the entire disk.
> Thus, if I labeled the third logical partition in FreeBSD style, I
> would only name the partitions in the logical partitions.  In OpenBSD,
> the primary partitions and the rest of the logical partitions would also
> be referenced in the disklabel.

Yes, I think NetBSD used to be like this too long ago.  What you are saying
is that there are two partition tables both speaking in terms of the whole
disk, and describing overlapping partitions.  Right?  Can you distinguish
this from the case of a disklabel sitting inside the first partition?  I
will assume you can; I guess worst case you can decide that a label whose
partitions would be too big to fit within the containing partition must in
fact be relative to the whole device.  In that case, I guess you could
provide alternative views as separate directories or something.  I dunno
what's most useful.

All of that aside, if you use the library that Parted uses, then the
important thing I think is to have a directory hierarchy that maps
naturally to the Parted user interface for looking at the partitions.  (Of
course, that interface might need hierarchical extensions as I've been
describing.  But that is really a secondary concern.)

> BTW, the next patch that I submit, do you want a patch against the first
> patch or against a clean tree?

Fresh patches against a shared image (such as some specified cvs version)
are always best.