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

[Pierre AUBERT]

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.

Best regards