[U-Boot] [PATCH 2/2] env export fix: compute the CRC on the real lenght of the exported variables.

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/03/2014 12:14 PM, Pierre AUBERT wrote:
> Dear Tom Rini
> 
> Le 26/02/2014 21:02, Tom Rini a écrit :
>> [ Catching up on some old emails ]
>>
>> On Fri, Nov 15, 2013 at 08:20:09AM +0100, Pierre AUBERT wrote:
>>> Dear Wolfgang Denk,
>>>
>>> Le 14/11/2013 18:24, Wolfgang Denk a écrit :
>>>> Dear Pierre Aubert,
>>>>
>>>> In message <1384434720-11214-3-git-send-email-p.aubert at staubli.com>
>>>> you wrote:
>>>>> Signed-off-by: Pierre Aubert <p.aubert at staubli.com>
>>>>> ---
>>>>>   common/cmd_nvedit.c |    5 +++--
>>>>>   1 files changed, 3 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
>>>>> index 5bcc324..c32a932 100644
>>>>> --- a/common/cmd_nvedit.c
>>>>> +++ b/common/cmd_nvedit.c
>>>>> @@ -922,14 +922,15 @@ NXTARG:        ;
>>>>>       len = hexport_r(&env_htab, '\0',
>>>>>               H_MATCH_KEY | H_MATCH_IDENT,
>>>>> -            &res, ENV_SIZE, argc, argv);
>>>>> +            &res, size, argc, argv);
>>>>> +
>>>>>       if (len < 0) {
>>>>>           error("Cannot export environment: errno = %d\n", errno);
>>>>>           return 1;
>>>>>       }
>>>>>       if (chk) {
>>>>> -        envp->crc = crc32(0, envp->data, ENV_SIZE);
>>>>> +        envp->crc = crc32(0, envp->data, len);
>>>> This is not correct.  When exporting with CRC, then the CRC
>>>> computation should be the same as is done with the persistently
>>>> stored environment, i. e. it should be taken over ENV_SIZE bytes.
>>> In this case, there's an inconstisency between the export and the
>>> import. It isn't possible to export some variables and the reimport
>>> them:
>>> U-Boot > env export -c <addr>
>>> U-Boot > env import -c <same addr> fails with a CRC error.
>>> The import computes the CRC on the real lenght of the environment
>>> variables. IMO, as the import and the export are done to work
>>> together, it seems to me that the export should compute its CRC on
>>> the real  lenght.
>> But env import -c <same addr> $filesize does work as the export sets
>> filesize.
>>
> 
> You're right, but my purpose wasn't  to export and reimport immediatly
> the same environment.
> I thought it was more logical to have the same behaviour between
> "sister" functions.

I see what you mean, yes.  I think that we need to make the size
parameter to import non-optional as assuming a whole ENV_SIZE chunk
would have been imported doesn't make sense.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTFLzwAAoJENk4IS6UOR1WM9sP/RriAefiFFrD5GcVURLfD6Ek
GDmPWuRg+NFEWHH/Z4eCyvxXaEurLnJcsVF8ZQblWT7zFYu+2weYpLPNYC/zKxzr
VDENmOHndPiDRzr5tfkXGiNXYWE46cSVysx5VYznRDH6sDsE+URJxXqZlefBZgw/
1l0ct5iQUWLmXkRJGQPsj7E4hpedUrBCNavoMh10adLZifWrtty03jN3sOerXhvE
qsAbm6ghrvtnC0b9Yj/FcyYFPgw0iG6VhLfCB10U7kwtVK4/Pl+QQNZaaDAPAgkN
OkdqiktIa5SyX4l94TBxb2Ixnxe7emZcub1WKrIa3zWNvy744e0bVPmtIVX1vYyT
GoaBTG+RcB0fnELt2Uj+odRqQS08KJrSJDOBzIiNzw0VlfSRwaXgK+wTl+3UY0Zt
JFiAPeOFGuYndWQJzRf/GKwhaElRV1NjLS1vFN1DHlNLjkv9xF5XJTiED+j7jGYQ
UCA26m75KtpAJXBjfE7Y7kyGENP6e9RxwSjwbnJcf0smbpIXi1KyU8bOXyriIK4e
oDtprRIxwfL0EdGAlbBNB+RfNxXjB+/lVsVyZyXjmDSeMogYqPIElhRsTMRJzsPx
upHUDvSeHqcTW/3nTtkBlnKTRRc+kze+fP3jwSsY06MWwQQxucvLdoqVzPKbQn/E
hBWjNm6FMSV0DYbaf1k8
=GS4O
-----END PGP SIGNATURE-----