From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= <benoit.thebaudeau@advansee.com>
Date: Sun, 12 Aug 2012 19:11:03 +0200 (CEST)
Subject: [U-Boot] [PATCH 5/5] Add env var giving the board revision
In-Reply-To: <201208121054.13838.vapier@gentoo.org>
Message-ID: <383502175.2331918.1344791463023.JavaMail.root@advansee.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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