From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gerlando Falauto <gerlando.falauto@keymile.com>
Date: Mon, 03 Sep 2012 09:33:21 +0200
Subject: [U-Boot] [PATCH v4 0/7] env: handle special variables and
	selective env default
In-Reply-To: <201209021813.44670.marex@denx.de>
References: <1321634955-5561-1-git-send-email-gerlando.falauto@keymile.com>
	<1345803102-21110-1-git-send-email-gerlando.falauto@keymile.com>
	<20120902115924.58EF9203B2F@gemini.denx.de>
	<201209021813.44670.marex@denx.de>
Message-ID: <50445D41.8070703@keymile.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 09/02/2012 06:13 PM, Marek Vasut wrote:
> Dear Wolfgang Denk,
>
>> Dear Gerlando Falauto,
>>
>> In message<1345803102-21110-1-git-send-email-gerlando.falauto@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.
>>>
>>> Changes in the syntax (user API):
>>> - "env default" -f: override write-once variables, -a means all
>>> - display a warning when trying to set to default variables not
>>>
>>>    present in the default env.
>>>
>>> Changes from v3:
>>> - rebased to current trunk (was not compilable)
>>> - removed compiler warnings
>>> - added an independent cosmetic patch on top of the series (from which
>>> only
>>>
>>>    a later patch would actually benefit)
>>
>> In which way are these changes related to the code I checked in for
>> testing into the "env" branch?
>>
>> Is this patch series supposed to replace this stuff?
>
> Yes, looks to me that way
>

Yes, as we (Holger and I) think it would make no sense to "patch the 
patch". But please correct me if I'm wrong.

Thank you,
Gerlando