From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 19 Nov 2019 19:45:30 -0500 Subject: [U-Boot] [PATCH 1/1] env: Exit tools when invalid CRC found In-Reply-To: References: <7f3c6ea239a26e247c43d1ddf6698f9f43973f76.camel@idexx.com> <20190505125049.GJ31207@bill-the-cat> <0510d854e2d983a7d24dad960bf1de53cef4cd5e.camel@idexx.com> Message-ID: <20191120004530.GL19317@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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: