Re: [PATCH RFC] efi: add and expose efi_partition_by_guid

[Will Drewry]

On Tue, Aug 3, 2010 at 1:23 PM, Kay Sievers <kay.sievers@xxxxxxxx> wrote:
> On Tue, Aug 3, 2010 at 19:55, Will Drewry <wad@xxxxxxxxxxxx> wrote:
>> On Tue, Aug 3, 2010 at 12:17 PM, Kay Sievers <kay.sievers@xxxxxxxx> wrote:
>>> On Tue, Aug 3, 2010 at 18:08, Tejun Heo <tj@xxxxxxxxxx> wrote:
>>>> On 08/02/2010 09:17 PM, Will Drewry wrote:
>>>>> EFI's GPT partitioning scheme expects that all partitions have a unique
>>>>> identifiers.  After initial partition scanning, this information is
>>>>> completely lost to the rest of the kernel.
>>>>>
>>>>> efi_partition_by_guid exposes GPT parsing support in a limited fashion
>>>>> to allow other portions of the kernel to map a partition from GUID to
>>>>> map.
>>>
>>>> Kay, you were talking about using GUID in GPT for finding out root
>>>> device and so on.  Does this fit your use case too?  If not it would
>>>> be nice to find out something which can be shared.
>>>
>>> Yeah, we have something similar in mind since a while, to be able to
>>> safely boot a box without an initramfs, and to be able to to specify
>>> something like:
>>>  root=PARTUUID=6547567-575-7567-567567-57
>>>  root=PARTLABEL=foo
>>> on the kernel commandline.
>>
>> Cool. So I'd like this as well (at least the UUID part), and I'd like
>> this to be available for other consumers in the kernel, like
>> dm_get_device() or at least for mapped device targets to implement
>> support for themselves.  (I have a separate patch for
>> mimicking md= for device mapper devices which I should probably post
>> to the lists again soon.)
>>
>>> The current 'blkid' already reports stuff like, to have the same
>>> information in userspace:
>>>  $ blkid -p -oudev /dev/sde1
>>>  ID_FS_LABEL=10GB
>>>  ID_FS_LABEL_ENC=10GB
>>>  ID_FS_UUID=5aafa1bb-70a7-4fe6-b93f-30658ec99fac
>>>  ID_FS_UUID_ENC=5aafa1bb-70a7-4fe6-b93f-30658ec99fac
>>>  ID_FS_VERSION=1.0
>>>  ID_FS_TYPE=ext4
>>>  ID_FS_USAGE=filesystem
>>>  ID_PART_ENTRY_SCHEME=gpt
>>>  ID_PART_ENTRY_UUID=1f765dcb-5214-bd47-b1c5-f2f18848335e
>>>  ID_PART_ENTRY_TYPE=a2a0d0eb-e5b9-3344-87c0-68b6b72699c7
>>>  ID_PART_ENTRY_NUMBER=1
>>>
>>> I guess we want to store these identifiers directly into the partition
>>> structure, independent of the partition format, so any code can
>>> register a callback for a new block device, and can just check if
>>> that's the device in question. Walking the block devices would just be
>>> something usual provided by the driver core, instead of having some
>>> specific EFI walk functions.
>>
>> Yeah - when I use this function, I end up doing a walk over all the
>> block devices, checking if they are whole disk entries, then calling
>> the efi_partition_by_guid() function. (Or the walker which I posted
>> separately.)  It's not ideal but it has the smallest impact on the
>> existing code. (Not having disk_type available is irritating though.)
>>
>> Would the type GUID and unique GUID be viable additions to a more
>> public struct?  If they were CONFIG_EFI_PARTITION guarded, then they
>> wouldn't waste memory for systems without GPT support, but it seems a
>> bit specific.  Also, I don't think it'd make sense to put it in the
>> partition struct as that represents the on-disk format for some tables
>> (from a quick scan over the code).  However, hd_struct looks the
>> sanest to me.
>>
>> I'd be happy to pull together a potential change that exposes this
>> data once after disk (re)scan, but I'd hate to do so in a way that'd
>> be fundamentally unacceptable (but I don't want to end up down the
>> deep hole of adding support across all the part tables either if I can
>> :).
>>
>> So I could see something like:
>>
>> struct hd_struct {
>> ...
>> #ifdef CONFIG_EFI_PARTITION
>>  efi_guid_t type_guid;
>>  efi_guid_t uuid;
>>  u16 label[72 / ...];
>> };
>>
>> Alternatively, a slightly more generic option might be:
>>
>> #ifdef CONFIG_PARTITION_INFO
>>  /* ASCII hex-formatted uuids inclusive of hyphens */
>>  u8 type_guid[MAX_HD_STRUCT_UUID_SIZE];
>>  u8 uuid[MAX_HD_STRUCT_UUID_SIZE];
>>  u16 label[MAX_HD_STRUCT_NAME + sizeof(u16)];
>> #endif
>>
>>
>> Any way, if any of this seems slightly palatable, let me know.  I'd
>> love to make this data accessible to the rest of the kernel.
>
> Maybe we go for a single pointer in the partition device, and allocate
> a struct partition_meta_info, or something like this, if we have such
> data to store. In that structure we can add all needed fields we need?
> That would not really waste anything if it's not needed, or it can
> possibly be free()d later, if nothing needs it anymore.

Sounds reasonable to me.  I'll see what I can cook up and post it back
to this thread.

cheers!
will
--
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/