Dear Joe, In message <CANr=Z=bccLDfjRwUOLMdy+11JA8ZO9+rP2mWZS=_kl_+wms...@mail.gmail.com> you wrote: > > On Tue, May 7, 2019 at 10:21 AM Molloy, Philip <philip-mol...@idexx.com> > wrote: > > > > On Sun, 2019-05-05 at 08:50 -0400, Tom Rini wrote: > > > Conceptually, yes, this is correct. However, the behavior in > > > question > > > has been deployed for so long that I don't feel that we can change it > > > at > > > this point, so I'm going to NAK this. Sorry. > > I certainly understand that constraint even though it has caused a fair > > amount of trouble. For a little more context please see an e-mail I > > sent to the Buildroot mailing list.[1] > > > > How about as a compromise fw_printenv still prints the same output, but > > it returns an exit code > 0 when doing so? > > Are you worried about the change to the exit code here? Are you > thinking there are some utilities that depend on it not erroring in > this case? > > If so, perhaps we can add a switch to the utility to have it actually > error in this case. If that's not a concern, maybe we can do it > without a switch. > > It would also be great to hear wdenx input.
The current behaviour of the fw_env tools corresponds to what U-Boot proper is doing: if there is a CRC error, it will fall back to the default environment, and continue. This is well known (and hopefully documented) behaviour. we have no idea how many existing use cases would break if we change the default behaviour of the fw_env tools. However, I agree that it is also a valid request to be able to recognize such CRC errors and handle them differently> I can see two different appraoches to implement this: 1) Add a new option to fw_env to return a specfic error code in this case (say 2 to be able to differentiate between such a "soft" error and "hard" I/O errors or such). 2) Implement a new "fw_test" command which just checks if the environment has a valid CRC and provides this information as return code. Give existing usage of the fw_end tools I tend to prefer 2), which does not change existing behaviour and only adds new functionality instead. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Let the programmers be many and the managers few -- then all will be productive. -- Geoffrey James, "The Tao of Programming" _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
