Re: [PATCH 2/2] genhd, efi: add efi partition metadata to hd_structs

[Will Drewry]

On Tue, Aug 3, 2010 at 4:54 PM, Kay Sievers <kay.sievers@xxxxxxxx> wrote:
> On Tue, Aug 3, 2010 at 23:35, Will Drewry <wad@xxxxxxxxxxxx> 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.
>>
>> Adding this information would make it possible to identify a
>> partition by GUID using something like disk_part_iter_*(),
>> calls that make hd_struct accessible, or even class_find_device.
>
> Wow, you are fast. :) Sounds and looks good to me.

Thanks!

> I guess we should assign the meta structure only after all values are
> filled in? Otherwise we could get partial reads from a possible user?

In add_partition(), I don't think the partition itself is shared until
rcu_assign_pointer is called, and I don't think that parsed_partitions
is safe to be shared inside check.c, but perhaps that's a dangerous
assumption

I can certainly move the pointer assignment to occur after the data is
copied over since it shouldn't hurt anything.

> Did you already test to put a lookup-call to the in-kernel mounter, if
> we use some special partition table uuid identifier for root=? That
> would be nice to see, if all that works as expected, and we can get to
> the data we collect.

Not yet, but I'd like to have it working there (and in my
device-mapper target) as soon as possible.  Hopefully, I'll have that
done pretty soon and I'll repost the series inclusive of an init:
change.

Any preferences on the variable? I'll start with your example of
PARTUUID=, but that follows the initramfs model (UUID=) and not the
existing magic root devices (/dev/nfs, /dev/ram).
/dev/by-part-uuid/XXX... doesn't seem super-friendly though :)

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/