fw_setenv: key-value assignment via cmdline vs. U-Boot

[Jan Kiszka]

Hi,

we've just migrated a device from U-boot-provided fw-tools to
libubootenv. But there is a subtle difference in the command line syntax:

U-Boot:
$ fw_setenv var val1 val2 val3
$ fw_printenv var
var=val1 val2 val3

libubootenv:
$ fw_setenv var val1 val2 val3
$ fw_printenv var val2
var=val1
val2=val3

Was that deviation intended? It bites us now as we documented the
previous behavior in end user instructions (fw_setenv boot_targets mmc1
mmc0 ...).

BTW, libubootenv only describes the command line options of its tools,
not positional parameters.

Thanks,
Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

[Stefano Babic]

Hi Jan,

On 11.02.22 16:55, Jan Kiszka wrote:
> Hi,
>
> we've just migrated a device from U-boot-provided fw-tools to
> libubootenv. But there is a subtle difference in the command line syntax:
>
> U-Boot:
> $ fw_setenv var val1 val2 val3
> $ fw_printenv var
> var=val1 val2 val3
>
> libubootenv:
> $ fw_setenv var val1 val2 val3
> $ fw_printenv var val2
> var=val1
> val2=val3
>
> Was that deviation intended?

It was, I do not remember when, but I got a patch for this.

Goal was to support both setting a variable with a list (old behavior),
and setting multiple variable in one line (new behavior).

In fact, delimiting the values, you get again the old u-boot-fw-utils
behavior:

fw_setenv var 'val1 val2 val3'

I get:

var=val1 val2 val3

but it is possible to write now:

# fw_setenv var 'val1 val2 val3' var2 val4
# fw_printenv | grep var
var=val1 val2 val3
var2=val4

The change is subtle but important: fw_setenv will store the new
environment just once, that is it is possible to save multiple variable
in an atomic way.

This is not possible with old u-boot-fw-utils, where we have:

fw_setenv var val1 val2 val3

fw_setenv var2 val4

and of course, this cannot be atomic. Both old u-boot-fw-utils and
libubootenv support scripts, and in that case the update is still atomic
(fw_setenv -s).

> It bites us now as we documented the
> previous behavior in end user instructions (fw_setenv boot_targets mmc1
> mmc0 ...).
>
> BTW, libubootenv only describes the command line options of its tools,
> not positional parameters.

There is a patch I forgot to apply to add some documentation for
fw_setenv, even if positional parameters are still missing:

http://patchwork.ozlabs.org/project/swupdate/patch/YYAuEMB4PdLHyhrd@q1/

I can apply it and extend to describe positional parameters.

Best regards,
Stefano


--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Jan Kiszka]

On 11.02.22 17:21, Stefano Babic wrote:
> Hi Jan,
>
> On 11.02.22 16:55, Jan Kiszka wrote:
>> Hi,
>>
>> we've just migrated a device from U-boot-provided fw-tools to
>> libubootenv. But there is a subtle difference in the command line syntax:
>>
>> U-Boot:
>> $ fw_setenv var val1 val2 val3
>> $ fw_printenv var
>> var=val1 val2 val3
>>
>> libubootenv:
>> $ fw_setenv var val1 val2 val3
>> $ fw_printenv var val2
>> var=val1
>> val2=val3
>>
>> Was that deviation intended?
>
> It was, I do not remember when, but I got a patch for this.
>
> Goal was to support both setting a variable with a list (old behavior),
> and setting multiple variable in one line (new behavior).
>
> In fact, delimiting the values, you get again the old u-boot-fw-utils
> behavior:
>
> fw_setenv var 'val1 val2 val3'
>
> I get:
>
> var=val1 val2 val3

Sure, this is what I intuitively did as well. But the old tools accepted
that without requiring quotes, thus we have a deviation in behavior.
Apparently desired but undocumented and for the user unexpected (with
possibly fatal effects as we described updating boot targets).

>
> but it is possible to write now:
>
> # fw_setenv var 'val1 val2 val3' var2 val4
> # fw_printenv  | grep var
> var=val1 val2 val3
> var2=val4
>
> The change is subtle but important: fw_setenv will store the new
> environment just once, that is it is possible to save multiple variable
> in an atomic way.
>
> This is not possible with old u-boot-fw-utils, where we have:
>
> fw_setenv var val1 val2 val3
> fw_setenv var2 val4
>
> and of course, this cannot be atomic. Both old u-boot-fw-utils and
> libubootenv support scripts, and in that case the update is still atomic
> (fw_setenv -s).
>
>> It bites us now as we documented the
>> previous behavior in end user instructions (fw_setenv boot_targets mmc1
>> mmc0 ...).
>>
>> BTW, libubootenv only describes the command line options of its tools,
>> not positional parameters.
>
> There is a patch I forgot to apply to add some documentation for
> fw_setenv, even if positional parameters are still missing:
>
> http://patchwork.ozlabs.org/project/swupdate/patch/YYAuEMB4PdLHyhrd@q1/
>
> I can apply it and extend to describe positional parameters.

OK, that would be good. A patch for fw_printenv [OPTIONS] [VARIABLE] ...
would be good as well. Just look at the old tools, they were way more
verbosely documented.

And we will need a patch for our docs now.