Dear Mike Frysinger,
I have searched such a usage in the tree, but did not find any, so this should not break anything.
You cannot expect to see the real, production environments in the mainline source tree.
Right, but the same applied to serial# and ethaddr when they were added, except if U-Boot deployment was not large enough at that time to worry you.
which makes all the difference in the world. those two variables were set up this way before 2002 (at least, that's according to the git history, and that's when the source code was first imported, so i can't easily check just how far back it goes). as the project grows up, policies evolve. -mike
OK. Actually, the only reason for which I need this patch is to make a variable read-only, and the only reason for which you reject it is because you fear that it breaks something.
So we could add a config like CONFIG_BOARD_REV_RO_VARIABLE to enable the code in my patch. But I think you won't like that either because you will find it too specific.
What about adding a config like CONFIG_READONLY_VARS that would be an array initializer containing the names of the board-specific variables to make read-only? _do_env_set() and fw_env_write() would use it besides the hard-coded serial# and the like. That would give something like: #define CONFIG_READONLY_VARS {"my_ro_var1", "my_ro_var2", "board_rev"} That would be a very simple solution to make everyone happy before Wolfgang implements a more sophisticated solution with read-only and volatile flags. What do you think?
Best regards, Benoît