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

[Andrew Clausen]

EVERYONE!

I usually go on xnet irc (see www.xnet.org), on channel #gnu, on
Saturday & Sunday mornings (~7:00 am -> 12:00) 

Everyone is invited to come along and chat ;-)

(actually, I'm often there other times as well, so come whenever
you want ;-)

I really should post summaries of some of the discussions I've had
with Lennert and Damien, and get them going on the mailing list...
I'll have a bit more of time from next week, and lots more time from
the end of November.

Anyway, IRC seems to be good for clearing up some Issues...

Timshel Knoll wrote:
> > Sorry, what's the difference between the two types?  Do you mean
> > "add a PedDiskType called bsd, and a PedPartitionType (or
> > PedFileSystemType?) called bsd"?
> 
> Yes, this is what I'm saying - a bsdlabel is a PedDiskType, and a
> bsdpart is a PedPartitionType. Much like the current extended/logical
> arrangement.

OK.

I'm wondering: do we need a separate PedPartitionType?  Why not use
PED_PARTITION_EXTENDED?  Then, use the partition flag interface to
specifiy BSD or DOS "extended" partitions.

Other features (like max # of logical partitions) could be controlled,
by interrogating the actual partition.

> > OK, this has Implications.  First, logical partitions
> > (== sub-partitions) must have owners expressed explicitly.  i.e.
> > a tree structure, with up links.
> 
> Yes, I think that this is probably the best way to do it. However,
> this has other implications (ie. mkpart for logical partitions
> will have to take an extra parameter than mkpart for primary partitions).

Perhaps:

        (parted) mkpart extended START END
        (parted) set MINOR bsd on

One problem is: you can only have 1 MSDOS extended partition.  It
could create a BSD one after exhausting MSDOS partitions, but this is
yuck.  Ultra-yuck.

> > Can sub-partitions be nested?  Can sub-partitions exist in logical
> > partitions?
> 
> No, I don't believe that you can have a disklabel within a disklabel ...
> The exception of course is having a disklabel within a primary DOS
> partition ...

huh?  why "primary"?  can't it be in a logical partition?

> > (/me REALLY should get freebsd...)
> 
> I'll burn you a copy if you want ... and it to you whenever we get
> together (BTW, monday lunch might be good ... I'm going to Adelaide
> this W/E and I just have to make sure that I'll be back ... I'll
> get back to you on this tho). I've also got OpenBSD and NetBSD if
> you want them as well. :-)

Sounds good :-)  BTW: this is my last week @ uni.  So, any day after
that is equally ok, basically ;-)

> > 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.)...
> 
> I believe that it would be good to get rid of any disklabel-specific
> stuff from all files other than disk_<disklabel-type>.c - ie. get
> rid of all stuff regarding 'primary' partitions or 'extended/logical'
> partitions from disk.c ... not that this is really possible, but
> hey ...

Well, I think things that affect the interface (include/parted/disk.h)
go in disk.c.  Removing logical/extended stuff from the interface
isn't possible - users need control here.

> > 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.
> 
> This always my preferred solution to a problem. Keeping any
> program/library modular is always the best way IMHO. This way it
> creates less problems in the future ... although it requires more
> changes in the present :-(

Go read http://www.jwz.org/doc/worse-is-better.html

The Right Thing TM doesn't always reduce problems in the future,
because if you can't adapt your nice modular system to a new
situation, you're stuffed...

Of course, what I'm getting at here is: when we support LVM and RAID
(probably via LVMS), what Issues are we going to face?  Are they
going to affect this?

eg: it may make sense to have a common abstraction for logical volumes
(LVM-speak) and partitions...

(logical volumes need not be continuous, or even on a single disk.
however, partitions seem to be a subset of logical volumes)

Should LVM be considered a type of "extended partition".  I think
not, because you can have many physical volumes forming an LVM.
OTOH, it might make sense to go the other way...

In fact, extended partitions (and LVM partitions) are really like
nested disk labels, EXCEPT the nested disk label has an Intimate
Relationship with parent (!) disk label.  It would be really cool
if we could think of a way of nesting disk labels, and making it
transparent to the user.

I really do like this select idea, just select is the wrong
interface...

Andrew Clausen