Re: SURVEY: precision in GNU Parted's user interface

[Andrew Clausen]

Hi Sven,

WARNING: if you haven't done the survey, this email might influence
your answers!  (This would be bad!)

On Sat, Apr 02, 2005 at 09:24:44AM +0200, Sven Luther wrote:
> Then a more generic analysis. I highly dislike this survey, and the
> supposition based solely on MBR that go with it.

I don't think any aspect of the survey is specific to MBR.  There are
varying degrees of problems wrt cylinder alignment on different
platforms.  eg: Sun absolutely requires cylinder alignment.  The more
general issue is about how constraints imposed by various partition
table types should interact with users.

> In particular cylinder boundaries are a thing of the past, not having
> any valid reality in current disks, so all your question about exact
> position and cylinder boundaries need to be taken modulo the
> constraint of the underlying partition table.

Agreed.  Those who know the details of cylinder alignment understand
this.  Those who don't will interpret the questions correctly, because
I explained that some programs don't work correctly if cylinders
aren't aligned.

> If a partition table has to have cylinder aligned partitions, then any
> partitions created by the user have to be cylinder aligned (in the
> case of the amiga/rdb, it is imposible to do otherwise anyway, i guess
> it is so for some others too).

Right.  Constraints that can't ever be broken will continue to be
strictly enforced by libparted.  However, if users are expecting Parted
to do exactly what they say, then perhaps we should be informing users
that their request was impossible rather than automagically doing
something slightly different.

> Also, i think it is meaningful to have the partition boundaries adapt to the
> surrounding stuff, and the = prefix to sizes is something that could be
> extended. One could imagine the following scheme : 
> 
>   1) value    -> handled in the best possible way as we currently do.
>   2) =value   -> the exact value, possibly fails if the underlying partition
>                    table is not able to use it, with a verbose message
>                  proposing the (two?) closest possibility.
>   3) <value   -> the same as 2), but adjusted to the lower possible boundary.
>   4) >value   -> same, but adjusted to the upper boundary.
>   5) ~value   -> adjusted to the next upper or lower partition boundary
>                  (depending if start or end)
>
> And even some more advanced stuff : 
> 
>   6) ~value-|+hole    -> the next lower/upper partition boundary, + or - a
>                          given hole. 

I agree that these are all possible and easy to implement.

> BTW, among the units, do we have a cylinder unit ? 

Yes.  It is called "cyl".

> BTW, does the unit stuff change the soname of libparted ? 

All of the changes are backward compatible, both in the user interface
and the API.  I'm not sure how libtool translates that into sonames,
but I believe the end result is that binaries linked against old
versions of libparted will still link against new libparted.

Cheers,
Andrew