All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] [PATCH 1/1] env: Exit tools when invalid CRC found
@ 2019-04-03 13:30 Molloy, Philip
  2019-05-05 12:50 ` Tom Rini
  0 siblings, 1 reply; 6+ messages in thread
From: Molloy, Philip @ 2019-04-03 13:30 UTC (permalink / raw)
  To: u-boot

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(-)

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 {
 		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:
-- 
2.20.1

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [U-Boot] [PATCH 1/1] env: Exit tools when invalid CRC found
  2019-04-03 13:30 [U-Boot] [PATCH 1/1] env: Exit tools when invalid CRC found Molloy, Philip
@ 2019-05-05 12:50 ` Tom Rini
  2019-05-07 15:09   ` Molloy, Philip
  0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2019-05-05 12:50 UTC (permalink / raw)
  To: u-boot

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190505/1dba6435/attachment.sig>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] [PATCH 1/1] env: Exit tools when invalid CRC found
  2019-05-05 12:50 ` Tom Rini
@ 2019-05-07 15:09   ` Molloy, Philip
  2019-11-20  0:06     ` Joe Hershberger
  0 siblings, 1 reply; 6+ messages in thread
From: Molloy, Philip @ 2019-05-07 15:09 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] [PATCH 1/1] env: Exit tools when invalid CRC found
  2019-05-07 15:09   ` Molloy, Philip
@ 2019-11-20  0:06     ` Joe Hershberger
  2019-11-20  0:45       ` Tom Rini
  2019-11-25  9:19       ` Wolfgang Denk
  0 siblings, 2 replies; 6+ messages in thread
From: Joe Hershberger @ 2019-11-20  0:06 UTC (permalink / raw)
  To: u-boot

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 at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] [PATCH 1/1] env: Exit tools when invalid CRC found
  2019-11-20  0:06     ` Joe Hershberger
@ 2019-11-20  0:45       ` Tom Rini
  2019-11-25  9:19       ` Wolfgang Denk
  1 sibling, 0 replies; 6+ messages in thread
From: Tom Rini @ 2019-11-20  0:45 UTC (permalink / raw)
  To: 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191119/d7f4b930/attachment.sig>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] [PATCH 1/1] env: Exit tools when invalid CRC found
  2019-11-20  0:06     ` Joe Hershberger
  2019-11-20  0:45       ` Tom Rini
@ 2019-11-25  9:19       ` Wolfgang Denk
  1 sibling, 0 replies; 6+ messages in thread
From: Wolfgang Denk @ 2019-11-25  9:19 UTC (permalink / raw)
  To: u-boot

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

-- 
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"

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-11-25  9:19 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-03 13:30 [U-Boot] [PATCH 1/1] env: Exit tools when invalid CRC found Molloy, Philip
2019-05-05 12:50 ` Tom Rini
2019-05-07 15:09   ` Molloy, Philip
2019-11-20  0:06     ` Joe Hershberger
2019-11-20  0:45       ` Tom Rini
2019-11-25  9:19       ` Wolfgang Denk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.