[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH] Add new partition type API and convert GPT type checks.

From: Michael Marineau
Subject: Re: [RFC PATCH] Add new partition type API and convert GPT type checks.
Date: Mon, 22 Sep 2014 13:03:30 -0700

On Mon, Sep 22, 2014 at 12:19 PM, Andrei Borzenkov <address@hidden> wrote:
> В Mon, 22 Sep 2014 11:59:06 -0700
> Michael Marineau <address@hidden> пишет:
>> This introduces a new type() function for partmaps modeled after the
>> label() and uuid() functions for filesystems. A likely future extension
>> will be support partition labels and uuids as well.
> Is there other partition type beyond GPT that supports it? What
> advantages it has over using filesystem label or uuid?

>From a quick glance through the other partmap modules looks like amiga
has parttype and apple has a parttype and partname. msdos of course
just has one byte types. As far as I can tell it is only GPT that has
all three: type, label, and uuid. I've started with just type since
that is what I need to make use of and copying the code to re-read the
type field yet again felt silly. My final goal is actually a module
that will search for two partitions of the same type and select
between them based on some other metadata. Since searching by
partition type is already a common task in the grub code base
providing an API to do so seemed like a good starting point. Others
will likely find extending this to support label and uuid more useful.
For example with GPT the Linux kernel can use
"root=PARTUUID=<someuuid>" directly, unlike LABEL= or UUID= which must
be implemented in an initrd.

>>                                                    This is in
>> preparation for adding more functionality like a search.part_type
>> command.
> What is use case? search is expected to return a single object; but you
> cannot presume uniqueness of partition of given type. That's different
> from label or uuid.

search.part_type is really just a useful test case for me but it could
be useful for finding the EFI System partition and similar special
boot partitions. It will be easy to extend to support
search.part_label or search.part_uuid which would be useful when
paired with root=PARTUUID= or when the filesystem information is
unknown or not significant.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]