| Message ID | 7f3c6ea239a26e247c43d1ddf6698f9f43973f76.camel@idexx.com |
|---|---|
| State | Rejected |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | [U-Boot,1/1] env: Exit tools when invalid CRC found | expand |
On Wed, Apr 03, 2019 at 01:30:47PM +0000, Molloy, Philip wrote: > fw_setenv and fw_printenv currently print a warning and use a default > environment compiled into the binary when an invalid CRC is found. This > modifies the default behavior to print an error and exit. This is > especially important when calling the tools from a script since the > script depends on the exit code of the tool to know something went > wrong. > > If the default environment is desired it should be read explicitly by > the caller. A better model is to store a default environment as a > separate binary or text file rather than storing it in the executable. > > Signed-off-by: Philip Molloy <philip-molloy@idexx.com> 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.
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? Best, Phil [1]: http://lists.busybox.net/pipermail/buildroot/2019-April/246761.html
Hi Tom, 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. Thanks, -Joe > Best, > Phil > > [1]: > http://lists.busybox.net/pipermail/buildroot/2019-April/246761.html > > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot
On Tue, Nov 19, 2019 at 06:06:27PM -0600, Joe Hershberger wrote: > Hi Tom, > > 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. Yes, my concern is scripts that either explicitly or implicitly depend on the current behavior. Making a new behavior with a flag seems fine to me.
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
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index a5d75958e1..ef33e9e1be 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -1438,9 +1438,8 @@ int fw_env_open(struct env_opts *opts) if (!have_redund_env) { if (!crc0_ok) { fprintf(stderr, - "Warning: Bad CRC, using default environment\n"); - memcpy(environment.data, default_environment, - sizeof(default_environment)); + "Invalid CRC found in environment\n"); + return -1; } } else {
fw_setenv and fw_printenv currently print a warning and use a default environment compiled into the binary when an invalid CRC is found. This modifies the default behavior to print an error and exit. This is especially important when calling the tools from a script since the script depends on the exit code of the tool to know something went wrong. If the default environment is desired it should be read explicitly by the caller. A better model is to store a default environment as a separate binary or text file rather than storing it in the executable. Signed-off-by: Philip Molloy <philip-molloy@idexx.com> --- tools/env/fw_env.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) flag0 = *environment.flags; @@ -1500,10 +1499,8 @@ int fw_env_open(struct env_opts *opts) dev_current = 1; } else if (!crc0_ok && !crc1_ok) { fprintf(stderr, - "Warning: Bad CRC, using default environment\n"); - memcpy(environment.data, default_environment, - sizeof(default_environment)); - dev_current = 0; + "Invalid CRC found in both redundant environments\n"); + return -1; } else { switch (environment.flag_scheme) { case FLAG_BOOLEAN: