Re: [PATCH v2 2/3] genhd, efi: add efi partition metadata to hd_structs
From: Will Drewry
Date: Wed Aug 04 2010 - 10:45:04 EST
On Wed, Aug 4, 2010 at 5:14 AM, Kay Sievers <kay.sievers@xxxxxxxx> wrote:
> On Wed, Aug 4, 2010 at 11:00, Karel Zak <kzak@xxxxxxxxxx> wrote:
>> On Tue, Aug 03, 2010 at 09:04:42PM -0500, Will Drewry wrote:
>>> This change extends the partition_meta_info structure to
>>> support EFI GPT-specific metadata and ensures that data
>>> is copied in on partition scanning.
>> Why do want to store GPT-specific data (efi_guid_t) to
>> partition_meta_info? I think it would be better to use label and uuid
>> in a generic format (e.g. string or u8 uuid) -- then you don't
>> have to use things like union, disklabel specific code to compare
>> uuids, etc. IMHO your current code is too complicated.
> I don't mind having the raw data and the type accessible. It might be
> useful for something we don't know about and it basically comes for
I'll bump out the uuid at least, but it might be worth keeping an
extended meta info option. But it's a lot less work to ditch it, so
I'm happy enough either way.
> But the only thing we are really interested in is the UUID, which,
> like Tejun already suggested, we should probably store
> format-independent, and have it always accessible. That way, we would
> not need any type-specific parser, we just handle the normal DCE
I'll bump it out and make it the efi code generic-ify its uuid. Out
of curiousity, were you and Tejun thinking of keeping it as a 36 byte
string or as the 16 byte packed value. While less space efficient,
I'd prefer the u8 as it avoids dealing with versioning when
parsing the user-supplied string. Instead, each partition type can
properly unparse its uuids according to what they expect.
> I don't think we should support any of the labels anyway in root= and
> similar, because they never really worked reliably with duplicates,
> and just ask for trouble.
Agreed. I don't think labels make sense, but we may later want to
support partition types (as I mention in my other mail).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/