From: Will Drewry on
On Thu, Aug 5, 2010 at 5:55 AM, Tejun Heo <tj(a)kernel.org> wrote:
> Hello,
>
> On 08/04/2010 08:22 PM, Will Drewry wrote:
>> @@ -642,6 +642,7 @@ void __init printk_all_partitions(void)
>> � � � � � � � struct hd_struct *part;
>> � � � � � � � char name_buf[BDEVNAME_SIZE];
>> � � � � � � � char devt_buf[BDEVT_SIZE];
>> + � � � � � � u8 uuid[PARTITION_META_INFO_UUIDLTH * 2 + 1];
>>
>> � � � � � � � /*
>> � � � � � � � �* Don't show empty devices or things that have been
>> @@ -660,10 +661,14 @@ void __init printk_all_partitions(void)
>> � � � � � � � while ((part = disk_part_iter_next(&piter))) {
>> � � � � � � � � � � � bool is_part0 = part == &disk->part0;
>>
>> - � � � � � � � � � � printk("%s%s %10llu %s", is_part0 ? "" : " �",
>> + � � � � � � � � � � uuid[0] = 0;
>> + � � � � � � � � � � if (part->info)
>> + � � � � � � � � � � � � � � part_unpack_uuid(part->info->uuid, uuid);
>> +
>> + � � � � � � � � � � printk("%s%s %10llu %s %s", is_part0 ? "" : " �",
>> � � � � � � � � � � � � � � �bdevt_str(part_devt(part), devt_buf),
>> � � � � � � � � � � � � � � �(unsigned long long)part->nr_sects >> 1,
>> - � � � � � � � � � � � � � �disk_name(disk, part->partno, name_buf));
>> + � � � � � � � � � � � � � �disk_name(disk, part->partno, name_buf), uuid);
>
> Hmmm... I'm a bit worried about this. �This might break userspace
> tools. �I think it would be better to export it via sysfs.

Cool - I'm happy to drop that part from the patch. I was more
following the spirit of the comment around making it easy for a user
to figure out what went wrong (e.g., wrong uuid) if they don't have a
root, but if there are tools parsing that output, I'd rather not break
them!

Would sysfs make sense as part of this patch series or would it be
fair game for a follow-on? I'm inclined to wait since the UUIDs can't
be changed (blkpg support isn't wired up) except with rescans, and a
userspace tool can just walk the partition table to get the uuids.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on
Hello,

On 08/05/2010 04:26 PM, Will Drewry wrote:
> On Thu, Aug 5, 2010 at 5:55 AM, Tejun Heo <tj(a)kernel.org> wrote:
>> Hello,
>>
>> On 08/04/2010 08:22 PM, Will Drewry wrote:
>>> @@ -642,6 +642,7 @@ void __init printk_all_partitions(void)
>>> struct hd_struct *part;
>>> char name_buf[BDEVNAME_SIZE];
>>> char devt_buf[BDEVT_SIZE];
>>> + u8 uuid[PARTITION_META_INFO_UUIDLTH * 2 + 1];
>>>
>>> /*
>>> * Don't show empty devices or things that have been
>>> @@ -660,10 +661,14 @@ void __init printk_all_partitions(void)
>>> while ((part = disk_part_iter_next(&piter))) {
>>> bool is_part0 = part == &disk->part0;
>>>
>>> - printk("%s%s %10llu %s", is_part0 ? "" : " ",
>>> + uuid[0] = 0;
>>> + if (part->info)
>>> + part_unpack_uuid(part->info->uuid, uuid);
>>> +
>>> + printk("%s%s %10llu %s %s", is_part0 ? "" : " ",
>>> bdevt_str(part_devt(part), devt_buf),
>>> (unsigned long long)part->nr_sects >> 1,
>>> - disk_name(disk, part->partno, name_buf));
>>> + disk_name(disk, part->partno, name_buf), uuid);
>>
>> Hmmm... I'm a bit worried about this. This might break userspace
>> tools. I think it would be better to export it via sysfs.
>
> Cool - I'm happy to drop that part from the patch. I was more
> following the spirit of the comment around making it easy for a user
> to figure out what went wrong (e.g., wrong uuid) if they don't have a
> root, but if there are tools parsing that output, I'd rather not break
> them!

Oh, forget about what I said. For some reason I thought the above
code was for /proc/partitions. :-)

Thanks.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Will Drewry on
On Thu, Aug 5, 2010 at 9:29 AM, Tejun Heo <tj(a)kernel.org> wrote:
> Hello,
>
> On 08/05/2010 04:26 PM, Will Drewry wrote:
>> On Thu, Aug 5, 2010 at 5:55 AM, Tejun Heo <tj(a)kernel.org> wrote:
>>> Hello,
>>>
>>> On 08/04/2010 08:22 PM, Will Drewry wrote:
>>>> @@ -642,6 +642,7 @@ void __init printk_all_partitions(void)
>>>> � � � � � � � struct hd_struct *part;
>>>> � � � � � � � char name_buf[BDEVNAME_SIZE];
>>>> � � � � � � � char devt_buf[BDEVT_SIZE];
>>>> + � � � � � � u8 uuid[PARTITION_META_INFO_UUIDLTH * 2 + 1];
>>>>
>>>> � � � � � � � /*
>>>> � � � � � � � �* Don't show empty devices or things that have been
>>>> @@ -660,10 +661,14 @@ void __init printk_all_partitions(void)
>>>> � � � � � � � while ((part = disk_part_iter_next(&piter))) {
>>>> � � � � � � � � � � � bool is_part0 = part == &disk->part0;
>>>>
>>>> - � � � � � � � � � � printk("%s%s %10llu %s", is_part0 ? "" : " �",
>>>> + � � � � � � � � � � uuid[0] = 0;
>>>> + � � � � � � � � � � if (part->info)
>>>> + � � � � � � � � � � � � � � part_unpack_uuid(part->info->uuid, uuid);
>>>> +
>>>> + � � � � � � � � � � printk("%s%s %10llu %s %s", is_part0 ? "" : " �",
>>>> � � � � � � � � � � � � � � �bdevt_str(part_devt(part), devt_buf),
>>>> � � � � � � � � � � � � � � �(unsigned long long)part->nr_sects >> 1,
>>>> - � � � � � � � � � � � � � �disk_name(disk, part->partno, name_buf));
>>>> + � � � � � � � � � � � � � �disk_name(disk, part->partno, name_buf), uuid);
>>>
>>> Hmmm... I'm a bit worried about this. �This might break userspace
>>> tools. �I think it would be better to export it via sysfs.
>>
>> Cool - I'm happy to drop that part from the patch. �I was more
>> following the spirit of the comment around making it easy for a user
>> to figure out what went wrong (e.g., wrong uuid) if they don't have a
>> root, but if there are tools parsing that output, I'd rather not break
>> them!
>
> Oh, forget about what I said. �For some reason I thought the above
> code was for /proc/partitions. �:-)

Cool - even better!

Thanks!
will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Kay Sievers on
On Wed, Aug 4, 2010 at 20:22, Will Drewry <wad(a)chromium.org> wrote:
> This is the third patch in a series which adds support for
> storing partition metadata, optionally, off of the hd_struct.
>
> One major use for that data is being able to resolve partition
> by other identities than just the index on a block device.  Device
> enumeration varies by platform and there's a benefit to being able
> to use something like EFI GPT's GUIDs to determine the correct
> block device and partition to mount as the root.
>
> This change adds that support to root= by adding support for
> the following syntax:
>
>  root=PARTUUID=hex-uuid

Just an update:

There is still no better idea than using this notation. We should
distinguish between filesystem and partiton UUIDs, and overloading
/dev with magic strings that will never exist there doesn't sound like
a good idea.

I checked with Karel, and fstab supports UUID=, initramfs tools
support root=UUID=, so we are probably going to have PARTUUID support
in fstab and initramfs too when we get there.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/