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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot