Re: Parted 1.6.12

[Andrew Clausen]

Hi Sven,

On Tue, Aug 31, 2004 at 01:56:22PM +0200, Sven Luther wrote:
> I have been tryint to upgrade the debian package from a patched 1.6.9 to this
> 1.6.12. Am i correct in thinking that the geometry change was the one which
> broke backward binary compatibility and forced a soname change, or was there
> something else involved ? 

struct PedDevice changed, including hw_geom and bios_geom.

If binaries were looking inside PedDevice, then they might break.

No public function prototypes changed.

> > Parted 1.6.12 is now available for download at ftp.gnu.org and
> > from CVS (cvs.alioth.debian.org:/cvsroot/parted, module "stable").
> > 
> > The big news in this release is that Parted now assigns an opinion
> > about what the CHS geometry is to each partition, rather than to
> > a whole device.  This means it is more robust when there are
> > inconsistent partition tables.
> > 
> > It also inspects file systems to find CHS geometry.
> 
> I also had to report the amiga patch, which you didn't apply to the
> main CVS tree (any particular reason for that ?).

Just lack of time... it is a low priority, and there are plenty of
high priority things left that need attention :/

I would like to have a good look at the code.  I had a quick look.

* you probably want to use that __attribute__ ((packed)) thing for structs.

* you also have too much error handling!  All libparted library calls
will throw exceptions on failure, so you don't need to throw an
exception yourself.  Eg: amiga_partition_duplicate() shouldn't throw
any exceptions.

> On amiga partition tables, the geometry is written in the partition
> table. When the partition table is first written, that data is read
> from the hw geometry (in the parted case), or using some more advanced
> heuristic (in the third party tools case). Since partitions are
> located on cylinder boundaries, this is rather important to get done
> right.

Does Linux on Amiga give reliable CHS information?

> When reading a partition table, i used to get the values from the
> partition table, and overwrite the dev->cylinders|heads|sectors data,
> and used that in the rest of it. Maybe this was not the best solution,
> but it seemed to work.

Sounds good to me.

> Now, we have a bios_geometry, and a
> hw_geometry. And which one would i need to set ? Also, i wonder what
> is the meaning of the bios_geometry on not-x86 hardware, but will
> probably need to check the source for it.

It's "user-defined" - i.e. up to the author of disk_*.c.
I want hw_geom to be strictly what the hard disk controller says it is,
and bios_geom to be what the OS/firmware/whatever say it is.
I am open to suggestions.

> Also, you don't seem to have updated doc/API.

Oops... fixed.

> > Together, these two features should make libparted much more robust
> > with DOS partition tables, and hopefully all the dual boot problems
> > will go away shortly.
> 
> What about non-DOS partition tables ?

I have no idea.  I hope I didn't change the semantics too much for
non-DOS tables.  Perhaps we need to use the GETGEO ioctl for non-x86?

Cheers,
Andrew