[U-Boot] Allow U-Boot scripts to be placed in a .env file

At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
to this file and dealing with quoting and newlines is harder than it
should be. It would be better if we could just type the script into a
text file and have it included by U-Boot.

Add a feature that brings in a .env file associated with the board
config, if present. To use it, create a file in include/configs
with the same name as you could board config file, except with a
.env extension instead of a .h extension. The variables should be
separated by \0. Comments are permitted, using # as the first character
in a line.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 Makefile                     | 25 ++++++++++++++++++++++++-
 README                       | 28 ++++++++++++++++++++++++++++
 include/env_default.h        |  2 ++
 mkconfig                     |  4 ++++
 tools/scripts/env2string.sed |  7 +++++++
 5 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 tools/scripts/env2string.sed

Dear Simon Glass,

In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
> At present U-Boot environment variables, and thus scripts, are defined
> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
> to this file and dealing with quoting and newlines is harder than it
> should be. It would be better if we could just type the script into a
> text file and have it included by U-Boot.
> 
> Add a feature that brings in a .env file associated with the board
> config, if present. To use it, create a file in include/configs
> with the same name as you could board config file, except with a
> .env extension instead of a .h extension. The variables should be
> separated by \0. Comments are permitted, using # as the first character
> in a line.

Please do not litter the include/configs/ directory with such stuff.
It's more than big enough already.  Please put such files into the
respective board directories.

And if you do something like this, then please go the way to the end.
Forget about the \0 termination, make it a plain text file instead,
something that can be used with "env import -t" as well (or created
with "env export -t").

Best regards,

Wolfgang Denk

On Wed, Apr 17, 2013 at 2:44 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>> At present U-Boot environment variables, and thus scripts, are defined
>> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>> to this file and dealing with quoting and newlines is harder than it
>> should be. It would be better if we could just type the script into a
>> text file and have it included by U-Boot.
>>
>> Add a feature that brings in a .env file associated with the board
>> config, if present. To use it, create a file in include/configs
>> with the same name as you could board config file, except with a
>> .env extension instead of a .h extension. The variables should be
>> separated by \0. Comments are permitted, using # as the first character
>> in a line.
>
> Please do not litter the include/configs/ directory with such stuff.
> It's more than big enough already.  Please put such files into the
> respective board directories.
>
> And if you do something like this, then please go the way to the end.
> Forget about the \0 termination, make it a plain text file instead,
> something that can be used with "env import -t" as well (or created
> with "env export -t").

It'd be nice if we could use #include or something there which might
allow reuse of env settings among several boards.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Hi Wolfgang,

On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>> At present U-Boot environment variables, and thus scripts, are defined
>> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>> to this file and dealing with quoting and newlines is harder than it
>> should be. It would be better if we could just type the script into a
>> text file and have it included by U-Boot.
>>
>> Add a feature that brings in a .env file associated with the board
>> config, if present. To use it, create a file in include/configs
>> with the same name as you could board config file, except with a
>> .env extension instead of a .h extension. The variables should be
>> separated by \0. Comments are permitted, using # as the first character
>> in a line.
>
> Please do not litter the include/configs/ directory with such stuff.
> It's more than big enough already.  Please put such files into the
> respective board directories.

OK.

>
> And if you do something like this, then please go the way to the end.
> Forget about the \0 termination, make it a plain text file instead,
> something that can be used with "env import -t" as well (or created
> with "env export -t").

I'm not sure how to do this. Doesn't this mean that we cannot add
multi-line scripts to the environment? That was part of my aim. But if
I put a 0x0a in the script then it will think we are starting a new
variable.

Perhaps we should automatically convert newline into semicolon? I
suspect that might work for most cases. But then exporting the text
file will not get the same thing as was imported.

I suppose I could use 0x0d as the line separator - it should be easy
enough to transparently convert this to and from 0x0a in 'env export
-t'.

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> Many companies that have made themselves dependent on [the  equipment
> of  a  certain  major  manufacturer] (and in doing so have sold their
> soul to the devil) will collapse under the sheer weight  of  the  un-
> mastered complexity of their data processing systems.
>           -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5

On Tue, Apr 23, 2013 at 02:32:00PM -0700, Simon Glass wrote:
> Hi Wolfgang,
> 
> On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Simon Glass,
> >
> > In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
> >> At present U-Boot environment variables, and thus scripts, are defined
> >> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
> >> to this file and dealing with quoting and newlines is harder than it
> >> should be. It would be better if we could just type the script into a
> >> text file and have it included by U-Boot.
> >>
> >> Add a feature that brings in a .env file associated with the board
> >> config, if present. To use it, create a file in include/configs
> >> with the same name as you could board config file, except with a
> >> .env extension instead of a .h extension. The variables should be
> >> separated by \0. Comments are permitted, using # as the first character
> >> in a line.
> >
> > Please do not litter the include/configs/ directory with such stuff.
> > It's more than big enough already.  Please put such files into the
> > respective board directories.
> 
> OK.
> 
> >
> > And if you do something like this, then please go the way to the end.
> > Forget about the \0 termination, make it a plain text file instead,
> > something that can be used with "env import -t" as well (or created
> > with "env export -t").
> 
> I'm not sure how to do this. Doesn't this mean that we cannot add
> multi-line scripts to the environment? That was part of my aim. But if
> I put a 0x0a in the script then it will think we are starting a new
> variable.

The first thing that pops to mind is:
1) embedded the text file into a linker-known spot
2) Make part of the default env setup process be to env import -t that
location in memory.

Hi Tom,

On Tue, Apr 23, 2013 at 4:33 PM, Tom Rini <trini@ti.com> wrote:
> On Tue, Apr 23, 2013 at 02:32:00PM -0700, Simon Glass wrote:
>> Hi Wolfgang,
>>
>> On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
>> > Dear Simon Glass,
>> >
>> > In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>> >> At present U-Boot environment variables, and thus scripts, are defined
>> >> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>> >> to this file and dealing with quoting and newlines is harder than it
>> >> should be. It would be better if we could just type the script into a
>> >> text file and have it included by U-Boot.
>> >>
>> >> Add a feature that brings in a .env file associated with the board
>> >> config, if present. To use it, create a file in include/configs
>> >> with the same name as you could board config file, except with a
>> >> .env extension instead of a .h extension. The variables should be
>> >> separated by \0. Comments are permitted, using # as the first character
>> >> in a line.
>> >
>> > Please do not litter the include/configs/ directory with such stuff.
>> > It's more than big enough already.  Please put such files into the
>> > respective board directories.
>>
>> OK.
>>
>> >
>> > And if you do something like this, then please go the way to the end.
>> > Forget about the \0 termination, make it a plain text file instead,
>> > something that can be used with "env import -t" as well (or created
>> > with "env export -t").
>>
>> I'm not sure how to do this. Doesn't this mean that we cannot add
>> multi-line scripts to the environment? That was part of my aim. But if
>> I put a 0x0a in the script then it will think we are starting a new
>> variable.
>
> The first thing that pops to mind is:
> 1) embedded the text file into a linker-known spot
> 2) Make part of the default env setup process be to env import -t that
> location in memory.

Well I have a working implementation - my concern was more about how
to deal with newlines. I would like to be able to handle a script just
written out over multiple lines in a text file. This is really nice
because we can have proper indenting, comments, etc. As soon as we
have to use 0x0a as the separator between each environment variable
that is no longer possible.

My current scheme requires the .env file to have \0 separating
environment variables which is obviously not ideal. I am hoping we can
find another way which is more textfile-friendly without losing the
benefits.

Regards,
Simon

>
> --
> Tom

On Tue, Apr 23, 2013 at 9:29 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
> On Tue, Apr 23, 2013 at 4:33 PM, Tom Rini <trini@ti.com> wrote:
>> On Tue, Apr 23, 2013 at 02:32:00PM -0700, Simon Glass wrote:
>>> Hi Wolfgang,
>>>
>>> On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
>>> > Dear Simon Glass,
>>> >
>>> > In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>>> >> At present U-Boot environment variables, and thus scripts, are defined
>>> >> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>>> >> to this file and dealing with quoting and newlines is harder than it
>>> >> should be. It would be better if we could just type the script into a
>>> >> text file and have it included by U-Boot.
>>> >>
>>> >> Add a feature that brings in a .env file associated with the board
>>> >> config, if present. To use it, create a file in include/configs
>>> >> with the same name as you could board config file, except with a
>>> >> .env extension instead of a .h extension. The variables should be
>>> >> separated by \0. Comments are permitted, using # as the first character
>>> >> in a line.
>>> >
>>> > Please do not litter the include/configs/ directory with such stuff.
>>> > It's more than big enough already.  Please put such files into the
>>> > respective board directories.
>>>
>>> OK.
>>>
>>> >
>>> > And if you do something like this, then please go the way to the end.
>>> > Forget about the \0 termination, make it a plain text file instead,
>>> > something that can be used with "env import -t" as well (or created
>>> > with "env export -t").
>>>
>>> I'm not sure how to do this. Doesn't this mean that we cannot add
>>> multi-line scripts to the environment? That was part of my aim. But if
>>> I put a 0x0a in the script then it will think we are starting a new
>>> variable.
>>
>> The first thing that pops to mind is:
>> 1) embedded the text file into a linker-known spot
>> 2) Make part of the default env setup process be to env import -t that
>> location in memory.
>
> Well I have a working implementation - my concern was more about how
> to deal with newlines. I would like to be able to handle a script just
> written out over multiple lines in a text file. This is really nice
> because we can have proper indenting, comments, etc. As soon as we
> have to use 0x0a as the separator between each environment variable
> that is no longer possible.
>
> My current scheme requires the .env file to have \0 separating
> environment variables which is obviously not ideal. I am hoping we can
> find another way which is more textfile-friendly without losing the
> benefits.

What about using \ as continuous line indicator and otherwise finish
the line, when parsing, wiht \0?

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Hi Otavio,

On Tue, Apr 23, 2013 at 7:14 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Tue, Apr 23, 2013 at 9:29 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Tom,
>>
>> On Tue, Apr 23, 2013 at 4:33 PM, Tom Rini <trini@ti.com> wrote:
>>> On Tue, Apr 23, 2013 at 02:32:00PM -0700, Simon Glass wrote:
>>>> Hi Wolfgang,
>>>>
>>>> On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
>>>> > Dear Simon Glass,
>>>> >
>>>> > In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>>>> >> At present U-Boot environment variables, and thus scripts, are defined
>>>> >> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>>>> >> to this file and dealing with quoting and newlines is harder than it
>>>> >> should be. It would be better if we could just type the script into a
>>>> >> text file and have it included by U-Boot.
>>>> >>
>>>> >> Add a feature that brings in a .env file associated with the board
>>>> >> config, if present. To use it, create a file in include/configs
>>>> >> with the same name as you could board config file, except with a
>>>> >> .env extension instead of a .h extension. The variables should be
>>>> >> separated by \0. Comments are permitted, using # as the first character
>>>> >> in a line.
>>>> >
>>>> > Please do not litter the include/configs/ directory with such stuff.
>>>> > It's more than big enough already.  Please put such files into the
>>>> > respective board directories.
>>>>
>>>> OK.
>>>>
>>>> >
>>>> > And if you do something like this, then please go the way to the end.
>>>> > Forget about the \0 termination, make it a plain text file instead,
>>>> > something that can be used with "env import -t" as well (or created
>>>> > with "env export -t").
>>>>
>>>> I'm not sure how to do this. Doesn't this mean that we cannot add
>>>> multi-line scripts to the environment? That was part of my aim. But if
>>>> I put a 0x0a in the script then it will think we are starting a new
>>>> variable.
>>>
>>> The first thing that pops to mind is:
>>> 1) embedded the text file into a linker-known spot
>>> 2) Make part of the default env setup process be to env import -t that
>>> location in memory.
>>
>> Well I have a working implementation - my concern was more about how
>> to deal with newlines. I would like to be able to handle a script just
>> written out over multiple lines in a text file. This is really nice
>> because we can have proper indenting, comments, etc. As soon as we
>> have to use 0x0a as the separator between each environment variable
>> that is no longer possible.
>>
>> My current scheme requires the .env file to have \0 separating
>> environment variables which is obviously not ideal. I am hoping we can
>> find another way which is more textfile-friendly without losing the
>> benefits.
>
> What about using \ as continuous line indicator and otherwise finish
> the line, when parsing, wiht \0?

Thanks for the suggestion. But that, along with the need for quotes,
is one of the reasons I would like to provide a way to enter scripts
naturally.

Adding \ at the end of each line is error-prone and gets in the way.
Python and C don't have this requirement - so why should U-Boot
scripts?

I wonder if we could define that 'xxx=' at the start of a line
delineates a new variable?

Regards,
Simon

>
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

On Tue, Apr 23, 2013 at 11:36 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Otavio,
>
> On Tue, Apr 23, 2013 at 7:14 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Tue, Apr 23, 2013 at 9:29 PM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Tom,
>>>
>>> On Tue, Apr 23, 2013 at 4:33 PM, Tom Rini <trini@ti.com> wrote:
>>>> On Tue, Apr 23, 2013 at 02:32:00PM -0700, Simon Glass wrote:
>>>>> Hi Wolfgang,
>>>>>
>>>>> On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
>>>>> > Dear Simon Glass,
>>>>> >
>>>>> > In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>>>>> >> At present U-Boot environment variables, and thus scripts, are defined
>>>>> >> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>>>>> >> to this file and dealing with quoting and newlines is harder than it
>>>>> >> should be. It would be better if we could just type the script into a
>>>>> >> text file and have it included by U-Boot.
>>>>> >>
>>>>> >> Add a feature that brings in a .env file associated with the board
>>>>> >> config, if present. To use it, create a file in include/configs
>>>>> >> with the same name as you could board config file, except with a
>>>>> >> .env extension instead of a .h extension. The variables should be
>>>>> >> separated by \0. Comments are permitted, using # as the first character
>>>>> >> in a line.
>>>>> >
>>>>> > Please do not litter the include/configs/ directory with such stuff.
>>>>> > It's more than big enough already.  Please put such files into the
>>>>> > respective board directories.
>>>>>
>>>>> OK.
>>>>>
>>>>> >
>>>>> > And if you do something like this, then please go the way to the end.
>>>>> > Forget about the \0 termination, make it a plain text file instead,
>>>>> > something that can be used with "env import -t" as well (or created
>>>>> > with "env export -t").
>>>>>
>>>>> I'm not sure how to do this. Doesn't this mean that we cannot add
>>>>> multi-line scripts to the environment? That was part of my aim. But if
>>>>> I put a 0x0a in the script then it will think we are starting a new
>>>>> variable.
>>>>
>>>> The first thing that pops to mind is:
>>>> 1) embedded the text file into a linker-known spot
>>>> 2) Make part of the default env setup process be to env import -t that
>>>> location in memory.
>>>
>>> Well I have a working implementation - my concern was more about how
>>> to deal with newlines. I would like to be able to handle a script just
>>> written out over multiple lines in a text file. This is really nice
>>> because we can have proper indenting, comments, etc. As soon as we
>>> have to use 0x0a as the separator between each environment variable
>>> that is no longer possible.
>>>
>>> My current scheme requires the .env file to have \0 separating
>>> environment variables which is obviously not ideal. I am hoping we can
>>> find another way which is more textfile-friendly without losing the
>>> benefits.
>>
>> What about using \ as continuous line indicator and otherwise finish
>> the line, when parsing, wiht \0?
>
> Thanks for the suggestion. But that, along with the need for quotes,
> is one of the reasons I would like to provide a way to enter scripts
> naturally.
>
> Adding \ at the end of each line is error-prone and gets in the way.
> Python and C don't have this requirement - so why should U-Boot
> scripts?
>
> I wonder if we could define that 'xxx=' at the start of a line
> delineates a new variable?

The problem with this kind of thing is we might end doing a full
parser and doing a semantic interpret of the text. It seems to be way
too complex ...

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Hi Otavio,

On Tue, Apr 23, 2013 at 7:44 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Tue, Apr 23, 2013 at 11:36 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Otavio,
>>
>> On Tue, Apr 23, 2013 at 7:14 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Tue, Apr 23, 2013 at 9:29 PM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Tom,
>>>>
>>>> On Tue, Apr 23, 2013 at 4:33 PM, Tom Rini <trini@ti.com> wrote:
>>>>> On Tue, Apr 23, 2013 at 02:32:00PM -0700, Simon Glass wrote:
>>>>>> Hi Wolfgang,
>>>>>>
>>>>>> On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
>>>>>> > Dear Simon Glass,
>>>>>> >
>>>>>> > In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>>>>>> >> At present U-Boot environment variables, and thus scripts, are defined
>>>>>> >> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>>>>>> >> to this file and dealing with quoting and newlines is harder than it
>>>>>> >> should be. It would be better if we could just type the script into a
>>>>>> >> text file and have it included by U-Boot.
>>>>>> >>
>>>>>> >> Add a feature that brings in a .env file associated with the board
>>>>>> >> config, if present. To use it, create a file in include/configs
>>>>>> >> with the same name as you could board config file, except with a
>>>>>> >> .env extension instead of a .h extension. The variables should be
>>>>>> >> separated by \0. Comments are permitted, using # as the first character
>>>>>> >> in a line.
>>>>>> >
>>>>>> > Please do not litter the include/configs/ directory with such stuff.
>>>>>> > It's more than big enough already.  Please put such files into the
>>>>>> > respective board directories.
>>>>>>
>>>>>> OK.
>>>>>>
>>>>>> >
>>>>>> > And if you do something like this, then please go the way to the end.
>>>>>> > Forget about the \0 termination, make it a plain text file instead,
>>>>>> > something that can be used with "env import -t" as well (or created
>>>>>> > with "env export -t").
>>>>>>
>>>>>> I'm not sure how to do this. Doesn't this mean that we cannot add
>>>>>> multi-line scripts to the environment? That was part of my aim. But if
>>>>>> I put a 0x0a in the script then it will think we are starting a new
>>>>>> variable.
>>>>>
>>>>> The first thing that pops to mind is:
>>>>> 1) embedded the text file into a linker-known spot
>>>>> 2) Make part of the default env setup process be to env import -t that
>>>>> location in memory.
>>>>
>>>> Well I have a working implementation - my concern was more about how
>>>> to deal with newlines. I would like to be able to handle a script just
>>>> written out over multiple lines in a text file. This is really nice
>>>> because we can have proper indenting, comments, etc. As soon as we
>>>> have to use 0x0a as the separator between each environment variable
>>>> that is no longer possible.
>>>>
>>>> My current scheme requires the .env file to have \0 separating
>>>> environment variables which is obviously not ideal. I am hoping we can
>>>> find another way which is more textfile-friendly without losing the
>>>> benefits.
>>>
>>> What about using \ as continuous line indicator and otherwise finish
>>> the line, when parsing, wiht \0?
>>
>> Thanks for the suggestion. But that, along with the need for quotes,
>> is one of the reasons I would like to provide a way to enter scripts
>> naturally.
>>
>> Adding \ at the end of each line is error-prone and gets in the way.
>> Python and C don't have this requirement - so why should U-Boot
>> scripts?
>>
>> I wonder if we could define that 'xxx=' at the start of a line
>> delineates a new variable?
>
> The problem with this kind of thing is we might end doing a full
> parser and doing a semantic interpret of the text. It seems to be way
> too complex ...

I can do the above with a simple sed script.

Do you mean we might create a new type of parser? If so, then we could
perhaps use a .scr extension or similar. My idea here is specifically
for environment.

Regards,
Simon

On Wed, Apr 24, 2013 at 12:05 AM, Simon Glass <sjg@chromium.org> wrote:
> On Tue, Apr 23, 2013 at 7:44 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Tue, Apr 23, 2013 at 11:36 PM, Simon Glass <sjg@chromium.org> wrote:
>>> Thanks for the suggestion. But that, along with the need for quotes,
>>> is one of the reasons I would like to provide a way to enter scripts
>>> naturally.
>>>
>>> Adding \ at the end of each line is error-prone and gets in the way.
>>> Python and C don't have this requirement - so why should U-Boot
>>> scripts?
>>>
>>> I wonder if we could define that 'xxx=' at the start of a line
>>> delineates a new variable?
>>
>> The problem with this kind of thing is we might end doing a full
>> parser and doing a semantic interpret of the text. It seems to be way
>> too complex ...
>
> I can do the above with a simple sed script.
>
> Do you mean we might create a new type of parser? If so, then we could
> perhaps use a .scr extension or similar. My idea here is specifically
> for environment.

I fully agree that the environment file should be as easy as possible
to be written. However I also think it should be parsed by CPP or
something which would allow us to 'include' other environment files
and enable/disable parts of it depending on board config. My ultimate
goal with it would be to allow sharing of environment setup across
different boards (for example the Freescale boards).

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Hi Otavio,

On Tue, Apr 23, 2013 at 8:20 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Wed, Apr 24, 2013 at 12:05 AM, Simon Glass <sjg@chromium.org> wrote:
>> On Tue, Apr 23, 2013 at 7:44 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Tue, Apr 23, 2013 at 11:36 PM, Simon Glass <sjg@chromium.org> wrote:
>>>> Thanks for the suggestion. But that, along with the need for quotes,
>>>> is one of the reasons I would like to provide a way to enter scripts
>>>> naturally.
>>>>
>>>> Adding \ at the end of each line is error-prone and gets in the way.
>>>> Python and C don't have this requirement - so why should U-Boot
>>>> scripts?
>>>>
>>>> I wonder if we could define that 'xxx=' at the start of a line
>>>> delineates a new variable?
>>>
>>> The problem with this kind of thing is we might end doing a full
>>> parser and doing a semantic interpret of the text. It seems to be way
>>> too complex ...
>>
>> I can do the above with a simple sed script.
>>
>> Do you mean we might create a new type of parser? If so, then we could
>> perhaps use a .scr extension or similar. My idea here is specifically
>> for environment.
>
> I fully agree that the environment file should be as easy as possible
> to be written. However I also think it should be parsed by CPP or
> something which would allow us to 'include' other environment files
> and enable/disable parts of it depending on board config. My ultimate
> goal with it would be to allow sharing of environment setup across
> different boards (for example the Freescale boards).

Your wish may be granted, I think this is easy enough, and we can
support #defines, etc. as well.

Regards,
Simon

Dear Simon Glass,

In message <CAPnjgZ0qqHab7md81XhQeY68EaJHa4VGPdVhz-Q=qPVZ99KCRw@mail.gmail.com> you wrote:
> 
> Do you mean we might create a new type of parser? If so, then we could
> perhaps use a .scr extension or similar. My idea here is specifically
> for environment.

Please do not invent yet another format, and yet another set of tools
around it.  I suggested this before:  Please use the very same simple
text format that is being used by "env import -t" and "env export -t".

Among other things, this provides an easy and elegant way both to
create the file (by using "env export" in a running system where you
could interactively develop and test your settings, and to verify the
settings using "env import" before actually compiling the code.

Best regards,

Wolfgang Denk

Dear Otavio Salvador,

In message <CAP9ODKpX_dFZ6K+frU6oamkQ3vKiYp9XYjaKX5Jn5PTq=0iyJQ@mail.gmail.com> you wrote:
>
> I fully agree that the environment file should be as easy as possible
> to be written. However I also think it should be parsed by CPP or
> something which would allow us to 'include' other environment files
> and enable/disable parts of it depending on board config. My ultimate
> goal with it would be to allow sharing of environment setup across
> different boards (for example the Freescale boards).

Don't overdesign this.  Keep it simple.  If you want, you can split up
the settings into several functional blocks (variable groups; this
could even be mapped into the actual U-Boot env, too).  Then simply
concatenate the right selection of parts.

See my previous message to Simon - keep the format compatible with
"env import/export -t".

Best regards,

Wolfgang Denk

Dies ist, was ich interessiert bin in.Welcome mich contace.

On 04/17/2013 12:44 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
> 
> In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>> At present U-Boot environment variables, and thus scripts, are defined
>> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>> to this file and dealing with quoting and newlines is harder than it
>> should be. It would be better if we could just type the script into a
>> text file and have it included by U-Boot.
>>
>> Add a feature that brings in a .env file associated with the board
>> config, if present. To use it, create a file in include/configs
>> with the same name as you could board config file, except with a
>> .env extension instead of a .h extension. The variables should be
>> separated by \0. Comments are permitted, using # as the first character
>> in a line.
> 
> Please do not litter the include/configs/ directory with such stuff.
> It's more than big enough already.  Please put such files into the
> respective board directories.
> 
> And if you do something like this, then please go the way to the end.
> Forget about the \0 termination, make it a plain text file instead,
> something that can be used with "env import -t" as well (or created
> with "env export -t").

What about allowing a binary created with mkenvimage to be built-in.
This would give us a standard build rule to build a separate env binary
as well.

Rob

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

On 05/06/2013 09:02 AM, Rob Herring wrote:
> On 04/17/2013 12:44 AM, Wolfgang Denk wrote:
>> Dear Simon Glass,
>> 
>> In message <1366155414-6525-1-git-send-email-sjg@chromium.org>
>> you wrote:
>>> At present U-Boot environment variables, and thus scripts, are
>>> defined by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add
>>> large amounts of text to this file and dealing with quoting and
>>> newlines is harder than it should be. It would be better if we
>>> could just type the script into a text file and have it
>>> included by U-Boot.
>>> 
>>> Add a feature that brings in a .env file associated with the
>>> board config, if present. To use it, create a file in
>>> include/configs with the same name as you could board config
>>> file, except with a .env extension instead of a .h extension.
>>> The variables should be separated by \0. Comments are
>>> permitted, using # as the first character in a line.
>> 
>> Please do not litter the include/configs/ directory with such
>> stuff. It's more than big enough already.  Please put such files
>> into the respective board directories.
>> 
>> And if you do something like this, then please go the way to the
>> end. Forget about the \0 termination, make it a plain text file
>> instead, something that can be used with "env import -t" as well
>> (or created with "env export -t").
> 
> What about allowing a binary created with mkenvimage to be
> built-in. This would give us a standard build rule to build a
> separate env binary as well.

With CONFIG_ENV_IS_EMBEDDED you should be able to do this today since
it has to be at a certain spot within the binary, yes?

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

iQIcBAEBAgAGBQJRh6zKAAoJENk4IS6UOR1WOT0P/2B1UX74nij7Z+8NJtiA/Ak5
QZlQw/tk7afZCOYPOxLnun6OCH6irWEPykBvtHGa3ww3f2L/lt8Kk3VTZprhhvTz
+s8YzDgFRAzPPbVfA5KSI2PUS0exNjVbQ8/mA+h8tPZ6G3XBsJCrvNyf6zGRUQK9
kr+RrZFUor0Z5xMyTOmba0rkTIKPmGLu+YhUQmFqCM0+5sjP0D+zpN68s89FwVah
Vxuf2Li7QmDp3PLNJphUFb67Vw/+JUCP+TZ/yLnAZlBScxTfNXPBspOlU3CkK4Dl
NgmfwAnd1wp8QCERWQD/jXFhjGY21QbogIvxs4tQWJ0TUxQnrFnCaX6iCwSe+kBE
Aesn/g+NhgQaj3GPJi5SvOwF5gXZPxXzvtywtoIMKeAoNC46JSk1y0wde7xzh4VP
0zrXRqE3SXW1wPKsKEBBUbE5F/tHiE1PxK2SRo5zq0s2gsPFLo2HT4G1sxE1XxVR
nft0TJ8EGaZ9h5B/sg1HFoT6ezMcoKjy/X7zVyBgUChIta9eJAUIwqAK3XNqSwhK
m5aWCqXDe03zufZ9M1dn9yWoKu4esyPdPQzUHcRZnbpVtKNpNN9obkF3s/LBqYme
9qyIf6DNTxBSV4NHB6PAT7ltrO6jau5mqkINtElSII6mf7A1OLUNZ/jLdkee2M07
tvi2uk6coQPwGTKr06aS
=Bk9E
-----END PGP SIGNATURE-----