Re: PATCH: fix gcc bug and big-endian issues for GPT

[Richard Hirst]

On Fri, Apr 05, 2002 at 02:47:24PM +1000, Andrew Clausen wrote:
> On Wed, Mar 20, 2002 at 12:03:34AM +0000, Richard Hirst wrote:
> >   This patch to parted 1.4 changes disk_gpt.c to keep the structures
> > representing on-disk data in little-endian format all the time.
> 
> I've been looking at this for 1.6.x.
> Can't we just comment out the ((packed)) thing, and all is well?
> 1-line fix?

That would work round the gcc bug, but:

1. It wouldn't make the code work on big-endian machines.
2. It wouldn't fix the problems with partition unique GUIDs having the
   wrong byte-order.
3. Kernel code has been changed is a similar way, so it makes some sense to
   keep parted in step.
4. Matt Domsch suggested this as the right way to go.

That said, (1) is not important at the moment, (2) doesn't seem to have
causes any problems so far, (3) and (4) are a matter of opinion.

> The 1.6.x gpt code is basically a rewrite.

Yes, I know.  I was planning on doing a sinilar patch for 1.6, but
didn't see much urgency until my copyright issues are resolved.

> BTW: if we get 1.6.0 out soon (like, once gpt is fixed, tommorrow is
> fine by me...), then is there a good reason to fix 1.4.x gpt as
> well?  Since the code is so different, it's probably not worth
> the effort to maintain both gpt implementations...

Debian woody release is "any day now", and will release with 1.4 as the
default parted version.  RedHat is using 1.4 at the moment, no idea
whether they would immediately switch or not.  For people with graphical
frontends on top of libparted1.4, does switching to 1.6 involve some
rework of their frontend?  If so, they might want to stick with 1.4 for
a while yet.

> (BTW: what do you think of the 1.6 implementation?)

Sorry, apart for noting how different it was, I havn't really looked
closely yet.  Seems 1.6.0-pre3 was the last version tried by the debian
buildds on ia64, and that failed to build, as I mentioned before.  Don't
know if those problems are resolved yet.

Richard