[U-Boot] [PATCH] gpt: add part-uuid and part-num subcommands

[Lukasz Majewski <l.majewski@majess.pl>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 3488 bytes --]

Hi Andrey,

> Hi Lukasz,
> 
> On Thu, Nov 9, 2017 at 2:28 PM, Lukasz Majewski
> <l.majewski@majess.pl> wrote:
> > On Thu, 9 Nov 2017 07:34:44 -0800
> > Andrey Yurovsky <yurovsky@gmail.com> wrote:
> >  
> >> On Thu, Nov 9, 2017 at 1:55 AM, Lukasz Majewski
> >> <l.majewski@majess.pl> wrote:  
> >> > Hi Andrey,
> >> >  
> >> >> Hi Otavio,
> >> >>
> >> >> On Wed, Nov 8, 2017 at 2:47 AM, Otavio Salvador
> >> >> <otavio.salvador@ossystems.com.br> wrote:  
> >> >> > On Tue, Nov 7, 2017 at 10:43 PM, your name
> >> >> > <yurovsky@gmail.com> wrote:  
> >> >> >> From: Andrey Yurovsky <yurovsky@gmail.com>
> >> >> >>
> >> >> >> It is useful to be able to retrieve a partition UUID or
> >> >> >> number given the partition label, for instance some systems
> >> >> >> use the partition label to indicate the purpose of the
> >> >> >> partition (such as "rootfs0" being the 0th root file system
> >> >> >> in an A/B image scheme).
> >> >> >>
> >> >> >> Add "gpt part-uuid" to retrieve the partition UUID for a
> >> >> >> given label and "gpt part-num" to retrieve the partition
> >> >> >> number for a given label along with some documentation.
> >> >> >>
> >> >> >> Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>  
> >> >> >
> >> >> > Why not use the 'part' cmd? it provides it.  
> >> >>
> >> >> Sorry, I missed the part cmd, it doesn't seem to be documented
> >> >> in doc/ and it's unclear what <dev> means there.  
> >> >
> >> > If I may ask - Andrey, if you are now on this "topic" - would you
> >> > dare to add some ./doc entry for 'part' command?  
> >>
> >> Yes, I will do that.  
> >
> > Thanks :-)  
> 
> On further investigation I am not sure that it's possible to extend
> the part command to retrieve UUIDs by label because of the design of
> the partition type drivers. Here is how I understand it to work:
> 1. the "part" command uses part_get_info() and in turn gets a
> partition driver and can call print() there (which is how EFI/GPT
> disks are printed with "part list"). The right information (including
> label) is printed but it's not tied to the caller in any way.

Maybe you can set some env variable with proper data?

For example, please refer to ./cmd/part.c do_part_start() function.

Example call from envs (include/configs/display5.h):
	"part start mmc ${mmcdev} ${kernel_part} lba_start; " \

> 2. "part uuid"  blk_get_device_part_str() which in turn can get
> information but referenced by partition number (and only partition
> number, due to how part_get_info() works). There's nothing at the
> 'part' layer tying a label to a number though so one would already
> need to know the number, which is the problem I'm trying to solve.
> 
> This layering keeps partitioning generalized and decoupled from the
> underlying partition "driver" but there's no concept of a label in the
> "driver" API. I'm not sure if it's reasonable to extend it since
> part_get_info() and similar really don't have a way to map labels at
> this layer so perhaps extending the GPT-specific command is the only
> reasonable approach?
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
Best regards,

Łukasz Majewski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171114/9f85a48a/attachment.sig>