Dear Tom,
In message <20211024164404.GQ3577824@bill-the-cat> you wrote:
>
> > It is a convenience tool, and it is OK if it has a few restrictions,
> > like for the character set of supported variable names.
> >
> > But:
> >
> > 1) These restrictions must be clearly documented, both in the commit
> > message and in the related documentation/readme.
> > 2) There should be another, more primitive way to generate
> > environment settings without these restrictions..
>
> First, in that we don't have tests today for any of the "interesting"
> possible variable options, I have no clue which ones even work as
> intended.
>
> Second, yes, an end result here should be that yes, the default
> environment should be more easily buildable and integrated with
> arbitrary tools, so if something else can parse it (libubootenv?) it can
> be done.
Actually I have an even more low-level approach in mind, like the
capability to include (or rather import) binary U-Boot environment
data given in the usual
<name1>=<value1>\0...<nameN>=<valueN>\0\0
form. This might come in handy if your data comes from exporting
the environmentof a running system.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
An expert is a person who avoids the small errors while sweeping on
to the grand fallacy.
