env: reworking + default/import individual vars
Get series with b4
b4 am [email protected]Versions newest first
- v0 Latest0 of 4 patches 0 repliesNew
Patches in v0 No applies recorded yet
None of the 4 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v0 yet.
Cover letter [U-Boot] [PATCH v0 0/4] env: reworking + default/import individual vars
Quoted 4 lines · Wolfgang Denk
Dear Gerlando Falauto,
Quoted 1 line · In message<[email protected]> you wrote:
Quoted 8 lines
Quoted 6 lines
I tested "env import" with and without -n. Same for "env default". Also tested special variables.
Quoted 1 line
For me, env import is broken now.
I am not able to see how it's obviously broken.
It just didn't work for me.
Honestly, I didn't try it against the latest master branch.
Quoted 10 lines
Quoted 3 lines
Perhaps you mean that when you don't provide an argument to -n, the following argument (e.g., -t) is interpreted as a variable name (and therefore consumed)? That doesn't look like an error to me.
Yes, this is a serious bug. Aor design problem.
The whole interface is wrong. I have just extendend "env export" to do a similar thing. The new syntax is:
env export [-t | -b | -c] [-s size] addr [var ...]
When/where? I can't see that in the latest master branch.
Quoted 8 lines
We should do exactly the same for "env
import", i. e. make the size parameter an option to be passed with "-s size", and pass the names of any variables to import as additional arguments:env import [-t | -b | -c] [-s size] addr [var ...]This also greatly simplifies the implementation.
Totally agree. Question is: won't that break all the existing scripts???
If you agree, I can post an updated patch with the same behavior for import. Although I am bit concerned about our scripts.
Best,
Gerlando Falauto