From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Fri, 9 Oct 2015 09:36:35 -0600 Subject: [U-Boot] Inconsistencies in commands regarding load_addr In-Reply-To: <56177AC8.1020707@wsystem.com> References: <5613E20F.8060306@wsystem.com> <20151008044015.BC4DB380905@gemini.denx.de> <56167DB6.3000508@wwwdotorg.org> <20151008212902.065EE382CD2@gemini.denx.de> <56177AC8.1020707@wsystem.com> Message-ID: <5617DF03.3050306@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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@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:-(