On Mon, Sep 22, 2014 at 12:19 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> В Mon, 22 Sep 2014 11:59:06 -0700
> Michael Marineau <michael.marin...@coreos.com> пишет:
>
>> 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.

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Reply via email to