From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefano Babic <sbabic@denx.de>
Date: Fri, 21 May 2010 18:39:00 +0200
Subject: [U-Boot] [PATCH] Tools: set multiple variable with fw_setenv
	utility
In-Reply-To: <20100521160351.CA8B3E67644@gemini.denx.de>
References: <1274439131-22807-1-git-send-email-sbabic@denx.de>
	<20100521113841.6243BCCF026@gemini.denx.de>
	<4BF6A381.7020200@denx.de>
	<20100521160351.CA8B3E67644@gemini.denx.de>
Message-ID: <4BF6B724.6090307@denx.de>
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

Wolfgang Denk wrote:

> Adding spaces to the variable value? This makes little sense to me.
> It's just a waste of storage space and boot time.

Well, I can agree with you, however I have already seen this case...

> If you feel your environment is so complicated to read that you want
> such "formatting", then rather structure your envrionment (see
> proposals on the list), and/or help improving the printenv
> capabilities to add sorting etc.

Ok, understood. I will change to support something like

<whitespaces>variable<whitespaces>value

> Who says that TAB would not be allowed?

..probably is more stranger as to have spaces....

> Of course it is. There is
> virtually no restriction on the content of the value of a variable.
> The only character that cannot be part of the value is '\0'.
> 
> [Of course it is not a wise decision to add non-printing or control
> characters, but you can do this, if you like.]

As I saw some leading whitespaces in a variable, I cannot remember a
case where I saw a TAB in a variable. But as it is not forbidden,
probably there is still this case !

> 
>>>> +	char dump[128];
>>> Ouch! That's short! Why do we need such an arbitrary limit?
>> We do not need a small value, but I have to set a value for fgets. A
>> bigger value should be enough, reporting an error if the line is too long.
> 
> But your code is not set up to handle the remainder of too long lines.
> It would be read as the next line and cause confusion.

Ah, ok, I get now the point.

> Why do you have to run this in two spearate passes at all - first
> scan, then process.
> 
> Why cannot you process each variable when you read it? The we would
> not need any array or list at all.

There is a reason, please tell me how good it is ;-)

I thought the code could be used not only as it is, but integrated in an
application linking the required object (only one, fw_env.o).
An application could internally generate a list of pairs variable/values
and needs a function to set them in the u-boot environment. This is the
reason of the int fw_setenv_multiple(fw_env_list *list, int count)
function. No need to use an external file, no need to call fw_setenv as
external process. An application could link fw_env.o and call
fw_setenv_multiple().

I agree with you that I can do everything in a single pass if we do not
provide such kind of external interface.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================