[PATCH 0/3] teach 'env default' to optionally keep runtime variables

[PATCH 0/3] teach 'env default' to optionally keep runtime variables

[Rasmus Villemoes]

Doing bringup of a board, part of my bootstrap logic is in U-Boot. So
when tweaking that logic, I was bitten by a previous completed
bootstrap having left a copy of the environment on the device, which
was imported and thus overrided the new logic.

So I thought, "ok, I'll just make sure to put 'env default -a' as the
first part of the bootstrap logic so I'm not bitten again". Alas, my
logic also relies on certain variables that are set by C code
(e.g. for detecting board variant), and doing 'env default -a' also
eliminates those.

Looking around, the hashtab code already supports a flag that does
exactly what I need, and exposing that is (morally) a one-liner.

Rasmus Villemoes (3):
  cmd/nvedit.c: teach 'env default' to optionally keep runtime variables
  test: env: check that non-mentioned variables to "env default" are
    preserved
  test: env: add some test cases for new "env default -k" flag

 cmd/nvedit.c          |  8 ++++++--
 test/env/cmd_ut_env.c | 45 ++++++++++++++++++++++++++++++++++++++++---
 2 files changed, 48 insertions(+), 5 deletions(-)

-- 
2.47.0

[PATCH 1/3] cmd/nvedit.c: teach 'env default' to optionally keep runtime variables

[Rasmus Villemoes]

It can be useful to set all variables defined in the default
environment to the value they have there, but without removing
variables that are only defined at runtime. This can sort-of be done
today, by using the "env default var1 var2 ..." variant, but that
requires listing all variables defined in the default
environment. It's much more convenient to be able to say

  env default -k -a

The -k flag is also meaningful in the other case: If var1 is not
defined in the default environment, but var2 is,

  env default var1 var2

would emit a warning about var1 not being in the default env and thus
being deleted. With -k, there's no warning, and var1 is kept as-is.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
---
 cmd/nvedit.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 392f90f8698..1f259801293 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -523,6 +523,9 @@ static int do_env_default(struct cmd_tbl *cmdtp, int flag,
 			case 'f':		/* force */
 				env_flag |= H_FORCE;
 				break;
+			case 'k':
+				env_flag |= H_NOCLEAR;
+				break;
 			default:
 				return cmd_usage(cmdtp);
 			}
@@ -1133,8 +1136,9 @@ U_BOOT_LONGHELP(env,
 #if defined(CONFIG_CMD_ENV_CALLBACK)
 	"callbacks - print callbacks and their associated variables\nenv "
 #endif
-	"default [-f] -a - [forcibly] reset default environment\n"
-	"env default [-f] var [...] - [forcibly] reset variable(s) to their default values\n"
+	"default [-k] [-f] -a - [forcibly] reset default environment\n"
+	"env default [-k] [-f] var [...] - [forcibly] reset variable(s) to their default values\n"
+	"      \"-k\": keep variables not defined in default environment\n"
 	"env delete [-f] var [...] - [forcibly] delete variable(s)\n"
 #if defined(CONFIG_CMD_EDITENV)
 	"env edit name - edit environment variable\n"
-- 
2.47.0

[PATCH 2/3] test: env: check that non-mentioned variables to "env default" are preserved

[Rasmus Villemoes]

Instead of testing the same expected behaviour for both
non_default_varX, test that when var1 is not in the default env but is
mentioned in the "env default" cmdline, it is removed, while var2 is
untouched.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
---
 test/env/cmd_ut_env.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/test/env/cmd_ut_env.c b/test/env/cmd_ut_env.c
index 4af05764fb8..e1dd1a14cb0 100644
--- a/test/env/cmd_ut_env.c
+++ b/test/env/cmd_ut_env.c
@@ -14,22 +14,21 @@ static int env_test_env_cmd(struct unit_test_state *uts)
 	ut_assertok(run_command("setenv non_default_var1 1", 0));
 	ut_assert_console_end();
 
-	ut_assertok(run_command("setenv non_default_var2 1", 0));
+	ut_assertok(run_command("setenv non_default_var2 2", 0));
 	ut_assert_console_end();
 
 	ut_assertok(run_command("env print non_default_var1", 0));
 	ut_assert_nextline("non_default_var1=1");
 	ut_assert_console_end();
 
-	ut_assertok(run_command("env default non_default_var1 non_default_var2", 0));
+	ut_assertok(run_command("env default non_default_var1", 0));
 	ut_assert_nextline("WARNING: 'non_default_var1' not in imported env, deleting it!");
-	ut_assert_nextline("WARNING: 'non_default_var2' not in imported env, deleting it!");
 	ut_assert_console_end();
 
 	ut_asserteq(1, run_command("env exists non_default_var1", 0));
 	ut_assert_console_end();
 
-	ut_asserteq(1, run_command("env exists non_default_var2", 0));
+	ut_asserteq(0, run_command("env exists non_default_var2", 0));
 	ut_assert_console_end();
 
 	return 0;
-- 
2.47.0

[PATCH 3/3] test: env: add some test cases for new "env default -k" flag

[Rasmus Villemoes]

Check that the new -k flag works as expected.

This also adds a test of the -a flag, which was previously missing,
and as the comment says, perhaps for a good reason. At least now we
have a test for it in combination with -k (and -f, because the ethaddr
variables otherwise cause complaining).

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
---
 test/env/cmd_ut_env.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/test/env/cmd_ut_env.c b/test/env/cmd_ut_env.c
index e1dd1a14cb0..9f16a978f2a 100644
--- a/test/env/cmd_ut_env.c
+++ b/test/env/cmd_ut_env.c
@@ -31,6 +31,46 @@ static int env_test_env_cmd(struct unit_test_state *uts)
 	ut_asserteq(0, run_command("env exists non_default_var2", 0));
 	ut_assert_console_end();
 
+	ut_assertok(run_command("setenv non_default_var1 3", 0));
+	ut_assert_console_end();
+
+	ut_assertok(run_command("env default -k non_default_var1", 0));
+	ut_assert_console_end();
+
+	ut_asserteq(0, run_command("env exists non_default_var1", 0));
+	ut_assert_console_end();
+
+	ut_asserteq(0, run_command("env exists non_default_var2", 0));
+	ut_assert_console_end();
+
+	ut_assertok(run_command("env default -k -a -f", 0));
+	ut_assert_nextline("## Resetting to default environment");
+	ut_assert_console_end();
+
+	ut_asserteq(0, run_command("env exists non_default_var1", 0));
+	ut_assert_console_end();
+
+	ut_asserteq(0, run_command("env exists non_default_var2", 0));
+	ut_assert_console_end();
+
+	/*
+	 * While the following test of "env default -a" by itself
+	 * works, it unfortunately causes an unrelated test case,
+	 * env_test_fdt_import(), to fail, because the "from_fdt"
+	 * variable would be removed.
+	 */
+#if 0
+	ut_assertok(run_command("env default -a", 0));
+	ut_assert_nextline("## Resetting to default environment");
+	ut_assert_console_end();
+
+	ut_asserteq(1, run_command("env exists non_default_var1", 0));
+	ut_assert_console_end();
+
+	ut_asserteq(1, run_command("env exists non_default_var2", 0));
+	ut_assert_console_end();
+#endif
+
 	return 0;
 }
 ENV_TEST(env_test_env_cmd, UTF_CONSOLE);
-- 
2.47.0

Re: [PATCH 0/3] teach 'env default' to optionally keep runtime variables

[Rasmus Villemoes]

On Wed, Oct 30 2024, Rasmus Villemoes <ravi@prevas.dk> wrote:

> Doing bringup of a board, part of my bootstrap logic is in U-Boot. So
> when tweaking that logic, I was bitten by a previous completed
> bootstrap having left a copy of the environment on the device, which
> was imported and thus overrided the new logic.
>
> So I thought, "ok, I'll just make sure to put 'env default -a' as the
> first part of the bootstrap logic so I'm not bitten again". Alas, my
> logic also relies on certain variables that are set by C code
> (e.g. for detecting board variant), and doing 'env default -a' also
> eliminates those.
>
> Looking around, the hashtab code already supports a flag that does
> exactly what I need, and exposing that is (morally) a one-liner.
>

ping

Re: [PATCH 0/3] teach 'env default' to optionally keep runtime variables

[Simon Glass]

Hi Rasmus,

On Wed, 13 Nov 2024 at 15:32, Rasmus Villemoes <ravi@prevas.dk> wrote:
>
> On Wed, Oct 30 2024, Rasmus Villemoes <ravi@prevas.dk> wrote:
>
> > Doing bringup of a board, part of my bootstrap logic is in U-Boot. So
> > when tweaking that logic, I was bitten by a previous completed
> > bootstrap having left a copy of the environment on the device, which
> > was imported and thus overrided the new logic.
> >
> > So I thought, "ok, I'll just make sure to put 'env default -a' as the
> > first part of the bootstrap logic so I'm not bitten again". Alas, my
> > logic also relies on certain variables that are set by C code
> > (e.g. for detecting board variant), and doing 'env default -a' also
> > eliminates those.
> >
> > Looking around, the hashtab code already supports a flag that does
> > exactly what I need, and exposing that is (morally) a one-liner.
> >

I didn't see the patch, but can you add a test?

Regards,
Simon

Re: [PATCH 0/3] teach 'env default' to optionally keep runtime variables

[Rasmus Villemoes]

On Fri, Nov 15 2024, Simon Glass <sjg@chromium.org> wrote:

> Hi Rasmus,
>
> On Wed, 13 Nov 2024 at 15:32, Rasmus Villemoes <ravi@prevas.dk> wrote:
>>
>> On Wed, Oct 30 2024, Rasmus Villemoes <ravi@prevas.dk> wrote:
>>
>> > Doing bringup of a board, part of my bootstrap logic is in U-Boot. So
>> > when tweaking that logic, I was bitten by a previous completed
>> > bootstrap having left a copy of the environment on the device, which
>> > was imported and thus overrided the new logic.
>> >
>> > So I thought, "ok, I'll just make sure to put 'env default -a' as the
>> > first part of the bootstrap logic so I'm not bitten again". Alas, my
>> > logic also relies on certain variables that are set by C code
>> > (e.g. for detecting board variant), and doing 'env default -a' also
>> > eliminates those.
>> >
>> > Looking around, the hashtab code already supports a flag that does
>> > exactly what I need, and exposing that is (morally) a one-liner.
>> >
>
> I didn't see the patch, but can you add a test?

That's literally patch 3/3.

Rasmus

Re: [PATCH 0/3] teach 'env default' to optionally keep runtime variables

[Tom Rini]

On Wed, 30 Oct 2024 22:34:01 +0100, Rasmus Villemoes wrote:

> Doing bringup of a board, part of my bootstrap logic is in U-Boot. So
> when tweaking that logic, I was bitten by a previous completed
> bootstrap having left a copy of the environment on the device, which
> was imported and thus overrided the new logic.
> 
> So I thought, "ok, I'll just make sure to put 'env default -a' as the
> first part of the bootstrap logic so I'm not bitten again". Alas, my
> logic also relies on certain variables that are set by C code
> (e.g. for detecting board variant), and doing 'env default -a' also
> eliminates those.
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom