Dear Joe,
In message CANr=Z=bccLDfjRwUOLMdy+11JA8ZO9+rP2mWZS=_kL_+wMSnyw@mail.gmail.com you wrote:
On Tue, May 7, 2019 at 10:21 AM Molloy, Philip Philip-Molloy@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