[U-Boot] [PATCH v3 3/7] gpt:doc: GPT (GUID Partition Table) documentation

[Lukasz Majewski]

Hi Stephen,

> On 09/13/2012 02:10 AM, Lukasz Majewski wrote:
> > Documentation of the GPT format.
> 
> > diff --git a/doc/README.gpt b/doc/README.gpt
> 
> > +Example usage:
> > +==============
> > +
> > +To restore GUID partition table one needs to:
> > +1. at ./include/configs/{board}.h
> > +   - define "partitions=" environment variable with format:
> > +
> > "name=u-boot,size=60M;name=kernel,size=60M;name=platform,size=1G;"
> > +   - define GPT_PARTS_NUM with actual number of partitions (as
> > defined above)
> 
> That seems unfortunate; the partitions variable and GPT_PARTS_NUM
> define could easily become out-of-sync (what if the user edited the
> variable in order to create an alternative disk layout, or what if a
> developer simply forgot to update GPT_PARTS_NUM when editing the
> hard-coded value?).
> 
> Instead, can't GPT_PARTS_NUM be removed, and the code simply count the
> number of entries in the partitions variable?

Yes, the GPT_PARTS_NUM can (and shall be replaced) with a runtime
detection of the number of available partitions. This can be done in a
similar way as it is done at DFU code.

> 
> > +   - #define CONFIG_EFI_PARTITION and #define CONFIG_CMD_GPT
> > +
> > +2. From u-boot prompt type:
> > +   gpt mmc 0 uuid_disk=ec2cddf2-fbf5-11e1-af3a-001fd09285c0, \
> > +   uuid1=ed09c4b0-fbf5-11e1-9a95-001fd09285c0, \
> > +   uuid2=edd6d93c-fbf5-11e1-875a-001fd09285c0, \
> > +   uuid3=f0485114-fbf5-11e1-a3ae-001fd09285c0 ...
> > +
> > +   UUIDs shall be defined up to GPT_PARTS_NUM. Smaller number is
> > acceptable.
> > +   When UUIDs are NOT provided, internal (rather weak) GUID
> > generator will be
> > +   used instead
> 
> Hmmm. It's a little unfortunate to provide the partitions list through
> one mechanism (environment variable with a hard-coded name), and the
> UUIDs through a different mechanism (command-line). Surely these two
> mechanisms can be combined; rather than the command reading an
> environment variable, you could at least require the user to pass the
> appropriate data on the command-line, and optionally have them pass
> the environment variable if they want to use the pre-defined layout,
> e.g.:
> 
> pre-defined:
> gpt mmc 0 ${partitions}
> 
> manual/custom layout:
> gpt mmc 0 name=u-boot,size=60M;name=kernel,size=60M;...
> 
> Then, I wonder if you couldn't define the partitions environment
> variable as:
> 
> partitions=\
> name=u-boot,size=60M,uuid=${uuid_gpt_u_boot};\
> name=kernel,size=60M,uuid=${uuid_gpt_kernel};...
> 
> and have the environment variables expanded as in:
> 
> setenv uuid_gpt_u_boot=ed09c4b0-fbf5-11e1-9a95-001fd09285c0
> setenv uuid_gpt_kernel=...

This is a good idea to allow uuid_gpt_u_boot= to be set via setenv.
Moreover I think, that "editing" of "partitions" names, uuid and other
parameters shall be done via setenv (as you proposed).

> gpt mmc 0 ${partitions}

Moreover I think, that parsing ${partitions} as a list of argv[n] is
not the best option to proceed.

I think that it would be easier to:
1. Prepare predefined "partitions=" variable
at ./include/configs/trats.h (when no one is available on the platform)
2. Edit relevant env variables (uuid_gpt_u_boot=, etc) via setenv and
saveenv.
3. restore it with gpt mmc 0 partitions (- the name of the stored and
prepared env variable)

I'd like to emphasis, that I strive to avoid parsing possibly (very)
long list of GPT partition definition via gpt command's argv[n].

If user wants to edit something, then one can use setenv to do that.

> 
> That way, the gpt command would read everything from the command-line,
> yet the partition layout and UUID names could be specified separately,
> so as to allow the user to define them at different times or places.
> 
> The implementation of "gpt" would have to scan all the variables it
> extracted from the command-line, and expand any environment variable
> references in them for this to work, since I assume the shell doesn't
> do recursive variable expansions like make does.
> 
> Oh, and don't you want the "gpt" command to take a sub-command like
> "create", so that "gpt" could do different things in the future, e.g.
> take an existing GPT layout, and edit, say, one partition's name:
> 

This is a nice idea to divide the gpt commands to subcommands. However
I now focus on gpt restoration (done in a correct and agreed way :-) ).
I will prepare the gpt command to be easily dividable to sub-commands.

> gpt create mmc 0 ${partitions}
> gpt set-name mmc 0 ${partition-id} ${new-name}



-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group