Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932816Ab0HCW1H (ORCPT ); Tue, 3 Aug 2010 18:27:07 -0400 Received: from mail-fx0-f46.google.com ([209.85.161.46]:48117 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756153Ab0HCW1F (ORCPT ); Tue, 3 Aug 2010 18:27:05 -0400 MIME-Version: 1.0 In-Reply-To: References: <1280871336-31046-2-git-send-email-wad@chromium.org> Date: Tue, 3 Aug 2010 17:27:04 -0500 Message-ID: Subject: Re: [PATCH 2/2] genhd, efi: add efi partition metadata to hd_structs From: Will Drewry To: Kay Sievers Cc: linux-kernel@vger.kernel.org, Jens Axboe , Karel Zak , Tejun Heo , "David S. Miller" , Andrew Morton , Joe Perches Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1998 Lines: 47 On Tue, Aug 3, 2010 at 4:54 PM, Kay Sievers wrote: > On Tue, Aug 3, 2010 at 23:35, 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. >> >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/