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
