All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Will Drewry <wad@chromium.org>
Cc: linux-kernel@vger.kernel.org, Jens Axboe <jens.axboe@oracle.com>,
	Karel Zak <kzak@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Joe Perches <joe@perches.com>, Kay Sievers <kay.sievers@vrfy.org>
Subject: Re: [PATCH RFC] efi: add and expose efi_partition_by_guid
Date: Tue, 03 Aug 2010 18:08:06 +0200	[thread overview]
Message-ID: <4C583EE6.4030203@kernel.org> (raw)
In-Reply-To: <1280776623-1337-1-git-send-email-wad@chromium.org>

(cc'ing Kay and quoting whole message for him)

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.

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.
> 
> An alternate implementation (and more generic) would be to expose a function
> (efi_partition_walk) that iterates over the partition table providing access to
> each partitions information to a callback, much like device class iterators.
> 
> The motivation for this change is the ability to have device mapper targets
> resolve backing devices by GUID instead of specifically by partition number.
> This could also be used in the init boot path (root=GUID) quite simply by
> modeling scanning code on printk_all_partitions(), or with another patchset
> allowing dm="" in the boot path: http://lkml.org/lkml/2010/6/7/418
> 
> [ Additional context: http://codereview.chromium.org/3026039/show ]
> 
> Would a change like this or something that exposes the GPT information via a
> walking function be something that would be of any interest, or is it explicitly
> against the current design/access goals with respect to partition information?
> 
> Any and all feedback is truly appreciated.
> 
> Signed-off-by: Will Drewry <wad@chromium.org>
> ---
>  fs/partitions/efi.c |   61 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/efi.h |    5 ++++
>  2 files changed, 66 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/partitions/efi.c b/fs/partitions/efi.c
> index 9efb2cf..4f642c5 100644
> --- a/fs/partitions/efi.c
> +++ b/fs/partitions/efi.c
> @@ -633,3 +633,64 @@ int efi_partition(struct parsed_partitions *state)
>  	printk("\n");
>  	return 1;
>  }
> +
> +/**
> + * efi_partition_by_guid
> + * @bdev:	Whole block device to scan for a GPT.
> + * @guid:	Unique identifier for the partition to find.
> + *
> + * N.b., returns on the first match since it should be unique.
> + *
> + * Returns:
> + * -1 if an error occurred
> + *  0 if there was no match (or not GPT)
> + *  >=1 is the index of the partition found.
> + *
> + */
> +int efi_partition_by_guid(struct block_device *bdev, efi_guid_t *guid) {
> +	gpt_header *gpt = NULL;
> +	gpt_entry *ptes = NULL;
> +	u32 i;
> +	struct parsed_partitions *state;
> +	int part = 0;
> +
> +	if (!bdev || !guid)
> +		return -1;
> +
> +	state = kzalloc(sizeof(struct parsed_partitions), GFP_KERNEL);
> +	if (!state)
> +		return -1;
> +
> +	state->limit = disk_max_parts(bdev->bd_disk);
> +	pr_debug(KERN_WARNING "efi_find_partition looking for gpt\n");
> +
> +	state->bdev = bdev;
> +	if (!find_valid_gpt(state,  &gpt, &ptes) || !gpt || !ptes) {
> +		pr_debug(KERN_WARNING "efi_find_partition no GPT\n");
> +		kfree(gpt);
> +		kfree(ptes);
> +		kfree(state);
> +		return 0;
> +	}
> +
> +	pr_debug("GUID Partition Table is valid!  Yea!\n");
> +	pr_debug(KERN_WARNING "efi_find_partition: 0 -> %d (limit:%d)\n",
> +		 le32_to_cpu(gpt->num_partition_entries),
> +		 state->limit);
> +	for (i = 0; i < le32_to_cpu(gpt->num_partition_entries) &&
> +		    i < state->limit-1; i++) {
> +		if (!is_pte_valid(&ptes[i], last_lba(bdev)))
> +			continue;
> +
> +		/* Bails on first hit so duped "unique" GUIDs will be FCFS. */
> +		if (!efi_guidcmp(ptes[i].unique_partition_guid,
> +				 *guid)) {
> +			part = i + 1;
> +			break;
> +		}
> +	}
> +	kfree(ptes);
> +	kfree(gpt);
> +	kfree(state);
> +	return part;
> +}
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index fb737bc..1a77259 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -301,6 +301,11 @@ extern unsigned long efi_get_time(void);
>  extern int efi_set_rtc_mmss(unsigned long nowtime);
>  extern struct efi_memory_map memmap;
>  
> +#ifdef CONFIG_EFI_PARTITION
> +struct block_device;
> +extern int efi_partition_by_guid(struct block_device *bdev, efi_guid_t *guid);
> +#endif
> +
>  /**
>   * efi_range_is_wc - check the WC bit on an address range
>   * @start: starting kvirt address

-- 
tejun

  parent reply	other threads:[~2010-08-03 16:08 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-02 19:17 [PATCH RFC] efi: add and expose efi_partition_by_guid Will Drewry
2010-08-02 23:00 ` David Miller
2010-08-03  2:44   ` Will Drewry
2010-08-03  2:52   ` [PATCH v2 " Will Drewry
2010-08-03 18:50     ` Randy Dunlap
2010-08-03 18:52       ` Will Drewry
2010-08-03  2:48 ` [PATCH RFC (alt)] efi: add efi_partition_walk and expose for kernel access Will Drewry
2010-08-03 16:08 ` Tejun Heo [this message]
2010-08-03 17:17   ` [PATCH RFC] efi: add and expose efi_partition_by_guid Kay Sievers
2010-08-03 17:55     ` Will Drewry
2010-08-03 18:23       ` Kay Sievers
2010-08-03 18:52         ` Will Drewry
2010-08-03 21:35           ` [PATCH 1/2] block, partition: add partition_meta_info to hd_struct Will Drewry
2010-08-03 21:35           ` [PATCH 2/2] genhd, efi: add efi partition metadata to hd_structs Will Drewry
2010-08-03 21:54             ` Kay Sievers
2010-08-03 22:27               ` Will Drewry
2010-08-03 23:13                 ` Kay Sievers
2010-08-04  2:04                   ` [PATCH v2 1/3] block, partition: add partition_meta_info to hd_struct Will Drewry
2010-08-04  7:57                     ` Tejun Heo
2010-08-04 14:46                       ` Will Drewry
2010-08-04  2:04                   ` [PATCH v2 2/3] genhd, efi: add efi partition metadata to hd_structs Will Drewry
2010-08-04  7:59                     ` Tejun Heo
2010-08-04  9:00                     ` Karel Zak
2010-08-04 10:14                       ` Kay Sievers
2010-08-04 14:44                         ` Will Drewry
2010-08-04 15:28                           ` Kay Sievers
2010-08-04 15:56                             ` Will Drewry
2010-08-04 18:22                               ` [PATCH v3 1/3] block, partition: add partition_meta_info to hd_struct Will Drewry
2010-08-04 18:22                               ` [PATCH v3 2/3] genhd, efi: add efi partition metadata to hd_structs Will Drewry
2010-08-04 18:22                               ` [PATCH v3 3/3] init: add support for root devices specified by partition UUID Will Drewry
2010-08-05 10:55                                 ` Tejun Heo
2010-08-05 14:26                                   ` Will Drewry
2010-08-05 14:29                                     ` Tejun Heo
2010-08-05 19:19                                       ` Will Drewry
2010-08-05 19:29                                 ` Kay Sievers
2010-08-31 20:47                                 ` [PATCH v4 1/3] block, partition: add partition_meta_info to hd_struct Will Drewry
2010-09-15 14:22                                   ` Jens Axboe
2010-08-31 20:47                                 ` [PATCH v4 2/3] genhd, efi: add efi partition metadata to hd_structs Will Drewry
2010-08-31 20:47                                 ` [PATCH v4 3/3] init: add support for root devices specified by partition UUID Will Drewry
2010-08-04 14:44                       ` [PATCH v2 2/3] genhd, efi: add efi partition metadata to hd_structs Will Drewry
2010-08-04  2:04                   ` [PATCH 3/3] init: add support for root devices specified by partition UUID Will Drewry
2010-08-04 14:27                   ` [PATCH 2/2] genhd, efi: add efi partition metadata to hd_structs John Stoffel
2010-08-04 14:45                     ` Will Drewry
2010-08-04 15:25                       ` Kay Sievers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C583EE6.4030203@kernel.org \
    --to=tj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=jens.axboe@oracle.com \
    --cc=joe@perches.com \
    --cc=kay.sievers@vrfy.org \
    --cc=kzak@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wad@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.