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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
