Re: Hacking parted to work with BSD disklabels ...

[Andrew Clausen]

Timshel Knoll wrote:
> Yes, I noticed that the extended/logical partition scheme is embedded
> within a lot of code in disk.c etc ....
> This is a problem I've come across. The method I thought of
> is not to use a 'select' command, but to add 2 new partition types:
> bsdlabel (or similar) and bsdpart.

Sorry, what's the difference between the two types?  Do you mean
"add a PedDiskType called bsd, and a PedPartitionType (or
PedFileSystemType?) called bsd"?

> This still leaves us with a fairly
> major problem - I believe that it is a valid configuration to have
> 2 (or more) BSD disklabels on the one disk - since *BSD refers to
> partitions/labels using a partition (slice, in BSD-ish) number and
> a letter indicating the sub-partition, ie:
> /dev/ad1s3a
> specifies the first sub-partition (a) in the disklabel on the 3rd
> disk slice (partition) (s3) on disk ad1 (hdb in linux-speak).

So, it is equivalent to extended partitions :-(
With very different alignment constraints, too... not that this
is going to be a big deal.

OK, this has Implications.  First, logical partitions
(== sub-partitions) must have owners expressed explicitly.  i.e.
a tree structure, with up links.

Can sub-partitions be nested?  Can sub-partitions exist in logical
partitions?

(/me REALLY should get freebsd...)

Also: do you have any inspiration on how to interface this stuff
on Parted?  And libparted?  It would be nice to preserve the
partition type (extended, logical, primary, etc.)...

Another issue is: is it really worth trying to hack libparted to
do this?  I think (in principle, although the details haven't
even been discussed yet...) that libparted will become part of
LVMS, or something similar, in the distant future.  Options:
* design an elegant (i.e. bloated) API to deal with the problem
the Right Way.
* write a minimal dodgey solution (like select), pending a better
one in something like LVMS ++
* ignore the problem (how important are BSD slices?  - I'm guessing
the answer is "important", so no need to push me on this one ;-)

++ we're probably the ones who will be designing this solution,
but it will be in a different context, so Everything might change.
OTOH, it might not... FWICT, we know more about partition tables
than the IBM people - I doubt they have solved this problem.
So, it's probably best we discuss the Right Solution TM now.

Andrew Clausen