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:
- These restrictions must be clearly documented, both in the commit message and in the related documentation/readme.
- 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