Re: Parted 1.6.12

[Andrew Clausen]

On Fri, Sep 03, 2004 at 09:30:59AM +0200, Sven Luther wrote:
> > I agree that putting stuff in arch_specific is "hiding", and you could
> > maintain backward compatability using this trick.  It is conceptually
> > very ugly, and I don't want to do this work myself.  It would be painful
> > for you Debian people to maintain the Parted package like this
> > long-term.
> 
> Bah, it will be in stable, so only security fixes will need to be involved.

I hope data corruption fixes would also be involved.

> > I think this is a time where you need to look at the code and say:
> > these are really trivially changes, and aren't going to break anything.
> > I think you should be far more concerned with the possibility of new
> > bugs in 1.6.12.
> 
> Yeah, ... 
> 
> Now, from a conceptual point of view, could you explain a bit more what you
> did, i am a bit confused about it, and the more i think of it, the more i feel
> the ugliness of the solution you proposed.
> 
> As i understand the code, the problem only affects the MBR based partition
> tables, and and the guessing involves only DOS/FAT/VFAT partitons (maybe also
> NTFS).

Basically correct.  There was an interface change, and all partition
table code (libparted/disk_*.c) conforms to this interface.
dev->hw_geom is supposed to have the geometry the hardware reports,
and dev->bios_geom is supposed to have the geometry the firmware uses
for booting.

dev->hw_geom is usually easy to get reliably.  dev->bios_geom is a pain
on x86.

For non-x86 arch's, the code assumes that the on-partition-table
geometry is right, and Parted will use this rather than dev->hw_geom.
It will overwrite dev->bios_geom with what it finds on the partition
table.

> I suppose that the guessing is done in the dos/fat/vfat probe code, which has
> no information whatsoever on the actual partition table code, which is the
> same reason i reimplemented partition table reading in the amiga filesystems
> to get the block size for them out of the amiga partition table.

Actually, the file system CHS-probing stuff is in libparted/disk_dos.c.
It's an ugly hack, but it's small, so I'm happy to keep it that way.

> So would a solution not be to reimplement a (basic) reading of the
> dos/fat/vfat/whatever filesystems, and getting only the geometry information
> of those in the MBR reading code, and then use the geometry heuristic there
> too to set the dev geometry. I do something similar in amiga partitions, where
> the geometry found on an existing partition table overrides the provided ones.

I'm not sure I understand this paragraph.  If you are proposing to
duplicate some file system code in libparted/disk_amiga.c for CHS
crap, then I like the idea.

> This way, there would be no compatibility lost, and only some minor
> duplication of code, and all in all, it is much more elegant code than the
> (bios|hw)_geom variant, where i suppose all partition tables except MBR's use
> hw_geom all over, right ? 

This seems to be a separate issue to me.

I would like to keep dev->bios_geom and dev->hw_geom because they might
be useful to software outside of libparted.

> And for user code, which did make use of dev->cyl|head|sector, which of the
> two geometry should they use ? Should they make checks for the partition type,
> and use bios if it is a MBR, and hw in other case ? 

It depends on the context.  If they are interested in what is useful for
booting / firmware compatability, they should use dev->bios_geom.

> Really sorry to not have participated in this discussion earlier, but i was
> overbusy with other stuff and such.

No problem :)  Volunteer projects work in spare time.

Cheers,
Andrew