[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Parted 1.6.12
Re: Parted 1.6.12
Tue, 31 Aug 2004 22:29:48 +1000
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
> 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
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.
> > 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?