[U-Boot] Inconsistencies in commands regarding load_addr

[Stephen Warren]

On 10/09/2015 02:28 AM, Benoît Thébaudeau wrote:
> Dear Wolfgang,
>
> On 08/10/2015 23:29, Wolfgang Denk wrote:
>> Dear Stephen,
>>
>> In message <56167DB6.3000508 at wwwdotorg.org> you wrote:
>>>
>>>>> What's the expected correct behavior here?
>>>>
>>>> After successful loading the data to memory, load_addr should be set
>>>> correctly, for all commands.  In the error case, the value of
>>>> load_addr is undefined.
>>>
>>> Is this documented anywhere? If not, I'm not convinced that there's a
>>> contract to be followed; it "just happens" that some filesystem-related
>>> commands work(ed) that way (and as Benoît pointed out, apparently some
>>> don't irrespective of the mentioned patch).
>>
>> I'm afraid it's not documented, but it is what I would consider a sane
>> and consistent behaviour.  If we intend to implement POLA [1] (and I
>> very much think we should), this is how U-Boot should behave.
>>
>>
>> [1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment
>
> I'm not certain that this would be the least astonishing behavior. When I read
> the documentation, I rather expect the loadaddr environment variable to be used
> whenever the address is omitted in a command invocation. Moreover, one may have
> to read/load several data pieces before booting, and the last loaded piece would
> not necessarily be the one containing the kernel to be booted. This should at
> least be documented.
>
> Another approach would be to compel users to pass an address for all commands.
> Implicit behaviors are always dangerous, all the more if they are undocumented.
> But of course, this would break some existing configurations.

I tend to agree with all of the above; U-Boot's 
implicit/automatic/hidden/undocumented usage of variables that I didn't 
specify on the command-line, and setting of variables as a side-effect 
of executing commands, has always been quite astonishing (rather than 
the opposite of astonishing) to me:-(