[U-Boot] [PATCH v3 0/6] env: handle special variables and selective env default

[Gerlando Falauto]

On 08/09/2012 10:17 PM, Wolfgang Denk wrote:
> Dear Gerlando Falauto,
>
> In message<1333391204-16318-1-git-send-email-gerlando.falauto at keymile.com>  you wrote:
>> This patchset modifies the handling of all the operations on the environment
>> (set/import/default) so to unify handling of special variables.
>> On top of that we implement a selective "env default".
>>
>> A selective "env import" would imply a user API change and should therefore
>> be discussed separately.
>>
>> NOTE:
>> The entire patchset generates an increase in code size of about 1200 bytes
>> on a PowerPC target.
>> As much as I would like to get rid of the set_default_vars() function in
>> env_common.c, I have not found a nice way to do so.
>
> It appears we are stuch with this patch set.  Last thing I remember
> was that Marek reviewed thes epatches, and had a few comments /
> requests for changes.  But I cannot remember having seen any more
> eplies from you.

As far as I can remember (or rather, as far as I can understand reading 
the whole thread once again), I had managed to persuade Marek to 
"accept" the first 5 patches out of 6 (I guess more by means of 
confusion than real arguments :-) )
Then on patch 6 we got stuck on:

 >> [me]
>> I'm not particularly fond of it either, but I'd rather do that than
>> overwrite the original array. Not that it's needed afterwards by the
>> caller...
>> Of course the same information (variables "used") could be tracked in
>> some other way (e.g. a bitmask array).

 > [Marek]
> Well won't bitfield suffice then?

[what I failed to reply]
I get the impression that would probably bloat the code even more, but I 
haven't checked that.

>> I'm not sure about the binary
>> code size, but it would just make things much more complicated to
>> read... and it's not like this feature (selective importing) is the core
>> of the bootloader, I guess.
>>
>> We can of course argue whether going through the hassle of deleting a
>> variable specified on the command line which is not defined in the
>> default/imported env is really the right thing to do (in other words,
>> whether the whole patch has the right to exist!), but that's a different
>> story. That's why I enqueued it as a separate patch.
> Honestly, I'm not in the position to properly argue here because I'm still
> making myself familiar with the env part of uboot
>

Which I remember interpreting as "I will follow up later"

>
> Is this correct?  So what is the current state?  Will there be any
> resubmission, or should these be applied as is,

I don't remember having any more leads to follow except for the bitfield 
part on the last (6th) patch. But I wouldn't call my memory a reliable 
source of information.
So please step forward if there's any suggestion.

> or should they be dropped altogether?

If anyone's counting hands, I'm voting against this latest action... :-)

Just so I know, are we talking about the merge window closing on August 
11th anyway?

Thanks,
Gerlando