Re: gcc bug causes parted to write bad GPT entries

[Richard Hirst]

On Sat, Mar 16, 2002 at 12:20:12PM +1100, Andrew Clausen wrote:
> This is going to cause lots of pain :(  (independently of libparted,
> since we can't use libuuid here, because intel defined it as
> little endian, not big-endian as the relevant RFC defines...)

disk_gpt.c uses libuuid to generate disk and partition unique GUIDs,
so I think we do still need to use it.

Currently disk_gpt.c (in 1.4) uses

uuid_unparse()

Only used in the GPT_DEBUG code to dump the table entries at present.
It prints the GUIDs with wrong byte order anyway, on LE machines.

uuid_generate()

Used to generate unique GUIDs, which currently end up with wrong byte
order.

Nothing in disk_gpt.c currently uses the fields in the efi_guid_t
struct, and if we were going to parse/unparse the GUIDs, it would be
nice to use libguid functions for that.  So, disk_gpt.c could treat
these GUIDs as arrays of 16 bytes.

The GUIDs are on disk in LE byte order, libuuid works in BE byte order.

Options:

1. Leave code as is, but add cpu_to_be()/be_to_cpu() swapping round calls
to libuuid.  Could just have be_to_cpu() after uuid_generate(), and have
local parse_le() unparse_le() functions.

2. Make gpt_disk.c do le_to_be()/be_to_le() when it reads/writes the
disk structures, and use libuuid to manipulate the GUID contents.
Should then really make efi_guid_t and array of 16 bytes, because it's
contents may be in the wrong byte order for accessing by struct member.

3. Probably some variations on the above.

Personally I favour (2) above; as these things are GUIDs, it makes sense
to use libuuid to manage them, and make disk_gpt.c unaware of their
structure, except for a small bit of code that interfaces to Intel's
on-disk format.

I can make a patch for (2), which would also nicely avoid the GCC
((packed)) bug, if there are no objections.

Cheers,
  Richard