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

[Stephen Warren]

On 10/05/2012 04:35 AM, Lukasz Majewski wrote:
> Hi Stephen,
> 
>> On 09/13/2012 02:10 AM, Lukasz Majewski wrote:
... [patch to implement GPT creation]
>> 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.

This forces the user to put the partition layout into an environment
variable. I don't like that idea. What if the user is running some
script on a recovery boot media to create the partition layout, rather
then restoring some partition layout defined in the default environment
in the board's U-Boot configuration file? Why should we force them to write:

setenv foo <<partition_layout>>
gpt create mmc 0 ${foo}

rather than simply:

gpt create mmc 0 <<partition_layout>>

The amount of work the command itself has to do for parsing is identical
or in fact slightly less; it just has to go to argv[4] and interpret it
as a partition list, rather than go to argv[4], read an environment
variable of that name and then interpret it as a partition list.
Admittedly, the command-shell has to do (very marginally) more work
since it has to scan more characters for the spaces that delimit
arguments, but I imagine that overhead is irrelevant compared to the
actual disk IO required to write the new partition tables, or even the
CPU calculations to calculate a UUID.

...
>> 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.

I certainly agree that the other sub-commands can be implemented later;
I just wanted to make sure that the command syntax was extensible in a
backwards compatible manner.