[U-Boot] [PATCH 1/1] env: Exit tools when invalid CRC found

[Wolfgang Denk]

Dear Joe,

In message <CANr=Z=bccLDfjRwUOLMdy+11JA8ZO9+rP2mWZS=_kL_+wMSnyw at mail.gmail.com> you wrote:
>
> On Tue, May 7, 2019 at 10:21 AM Molloy, Philip <Philip-Molloy at 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: wd at denx.de
Let the programmers be many and the managers few -- then all will  be
productive.               -- Geoffrey James, "The Tao of Programming"