[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gcc bug causes parted to write bad GPT entries

From: Richard Hirst
Subject: Re: gcc bug causes parted to write bad GPT entries
Date: Mon, 18 Mar 2002 11:48:18 +0000
User-agent: Mutt/1.3.24i

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


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.


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

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.


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]