init: add support for root devices specified by partition UUID
in [Kernel]
|
Prev: vmscan: synchrounous lumpy reclaim use lock_page() instead trylock_page()
Next: [PATCH 0/2 V2 resend] Driver for Ricoh cardreader + few fixes
From: Will Drewry on 5 Aug 2010 10:30 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 5 Aug 2010 10:30 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 5 Aug 2010 15:20 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 5 Aug 2010 15:30
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/ |