bg_setenv without parameters

[Jan Kiszka]

Hi Andreas,

what is bg_setenv without any parameters supposed to do, and what does
it actually - besides printing a suspicious "Environment update was
successful."?

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[Andreas Reichel]

On Mon, Mar 05, 2018 at 01:01:14PM +0100, Jan Kiszka wrote:
> Hi Andreas,
>
> what is bg_setenv without any parameters supposed to do, and what does
> it actually - besides printing a suspicious "Environment update was
> successful."?
>

Good point, thanks for asking.

If you specify no parameter, the program goes into
(write_mode), since you call bg_setenv and not bg_printenv.

Output to file is false, since no "-f" given.

auto_update is false, since no "-u" given.

part_specified is false, since no "-p" given.

This means, the program opens the latest environment and then calls
update_environment(env_new), where env_new is a handle to the latest
environment. (nothing new created at this point).

update_environment then processes an empty task list which does not
change the latest environment. It then recalculates the CRC32 again.

The program then stores the unmodified environment together with the
recalculated CRC32 back into the same place and exits.

Thus, bg_setenv without parameters performs a NOP on the current
environment data except the CRC and writes the values back again.

Thus, the question here is "what is the default behavior, a program
should have, if started without any parameter".

I would say, in case of bg_setenv, the behavior is not offbeat, the
message is true and if the user has doubts about what to do, he should
use --help anyway. Per definition, all arguments are optional, therefore
it would be strange if the help page was printed as if the user missed
something, since optional arguments are not required per definition.

Andreas

> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

--
Andreas Reichel
Dipl.-Phys. (Univ.)
Software Consultant

Andreas...@tngtech.com
+49-174-3180074

TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterföhring
Geschäftsführer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Müller
Sitz: Unterföhring * Amtsgericht München * HRB 135082

[Jan Kiszka]

On 2018-03-05 13:24, Andreas Reichel wrote:
> On Mon, Mar 05, 2018 at 01:01:14PM +0100, Jan Kiszka wrote:
>> Hi Andreas,
>>
>> what is bg_setenv without any parameters supposed to do, and what does
>> it actually - besides printing a suspicious "Environment update was
>> successful."?
>>
>
> Good point, thanks for asking.
>
> If you specify no parameter, the program goes into
> (write_mode), since you call bg_setenv and not bg_printenv.
>
> Output to file is false, since no "-f" given.
>
> auto_update is false, since no "-u" given.
>
> part_specified is false, since no "-p" given.
>
> This means, the program opens the latest environment and then calls
> update_environment(env_new), where env_new is a handle to the latest
> environment. (nothing new created at this point).
>
> update_environment then processes an empty task list which does not
> change the latest environment. It then recalculates the CRC32 again.
>
> The program then stores the unmodified environment together with the
> recalculated CRC32 back into the same place and exits.
>
> Thus, bg_setenv without parameters performs a NOP on the current
> environment data except the CRC and writes the values back again.
>
> Thus, the question here is "what is the default behavior, a program
> should have, if started without any parameter".

Right, and what is the use case behind it.

>
> I would say, in case of bg_setenv, the behavior is not offbeat, the
> message is true and if the user has doubts about what to do, he should
> use --help anyway. Per definition, all arguments are optional, therefore
> it would be strange if the help page was printed as if the user missed
> something, since optional arguments are not required per definition.

Normally, one model such a tool via subcommands:

tool subcommand [OPTIONS]

Unless there is a case for the current default behaviour. But it seems
like it is rather a side effect of the normal use cases.

[Andreas Reichel]

In the very beginning the idea was to have the 'bg_setenv/printenv' pair
modelled like 'fw_setenv/printenv' from U-Boot, where no subcommands
are used.

If we use sub-commands anyway, it does not make sense to have two
different names for the program but rather a
bg_envtool or so with

bg_envtool set

and

bg_envtool get

which is not as elegant imho and which still makes the arguments what to
set optional. I guess the easiest way to cope with that is to just
output

"Nothing specified, no tasks to do, exiting"

if no arguments are passed.

Andreas

> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

> --
> You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to efibootguard-d...@googlegroups.com.
> To post to this group, send email to efibootg...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/b3006f0a-77a0-e67f-1cd9-f93f34f22721%40siemens.com.
> For more options, visit https://groups.google.com/d/optout.

--
Andreas Reichel
Dipl.-Phys. (Univ.)
Software Consultant

Andreas...@tngtech.com, +49-174-3180074
TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring
Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller
Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082

[Jan Kiszka]

It rather seems we would then need bg_envtool set <subsubcommand> - I
don't think that is useful.

We currently have bg_setenv -c | -i | -s | -u, right? That could become
bg_setenv confirm_update | start_update | ... and keep bg_printenv. At
least we should define which switches are at least needed in order to do
something useful (still considering the parameter-free invocation useless).

Jan

>
> and
>
> bg_envtool get
>
> which is not as elegant imho and which still makes the arguments what to
> set optional. I guess the easiest way to cope with that is to just
> output
>
> "Nothing specified, no tasks to do, exiting"
>
> if no arguments are passed.
>
> Andreas
>

[Andreas Reichel]

Well... start_update does not make sense from the tool's point of view.

There already are long names for the switches. And one of the
advantages is that they can be combined... which is not the case if
we change them into sub-commands.

For example, one can use -u -x test=1 -c to automatically create a new
environment revision, set a user variable and immediately confirm
without further testing.

Or if we want to simulate a failed update finalization on config
partition number 0:
-p 0 -k kernel-name -c -i 1

which sets in_progress after confirming to see how the bootloader
reacts.

I agree in any case to solve this strange behavior (calling without
any arguments) by outputting "Nothing to do. Please specify at least
one optional parameter (see --help for further information)."

But, categorizing into sub-commands does
* limit our usage possibilities
* increase code complexity
* break the way the tool is used

Andreas

>
> Jan
>
> >
> > and
> >
> > bg_envtool get
> >
> > which is not as elegant imho and which still makes the arguments what to
> > set optional. I guess the easiest way to cope with that is to just
> > output
> >
> > "Nothing specified, no tasks to do, exiting"
> >
> > if no arguments are passed.
> >
> > Andreas
> >
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

[Jan Kiszka]

If the tool is too low-level for such an abstraction, well. It's usage
is definitely not intuitive yet to guide the user through typical workflows.

>
> There already are long names for the switches. And one of the
> advantages is that they can be combined... which is not the case if
> we change them into sub-commands.

You can always abbreviate long subcommands after a sufficient amount of
distinguishing characters. Common pattern in many tools. And/or provide
bash_completion.

>
> For example, one can use -u -x test=1 -c to automatically create a new
> environment revision, set a user variable and immediately confirm
> without further testing.
>
> Or if we want to simulate a failed update finalization on config
> partition number 0:
> -p 0 -k kernel-name -c -i 1
>
> which sets in_progress after confirming to see how the bootloader
> reacts.
>
> I agree in any case to solve this strange behavior (calling without
> any arguments) by outputting "Nothing to do. Please specify at least
> one optional parameter (see --help for further information)."

That would already improve the situation, indeed.

>
> But, categorizing into sub-commands does
> * limit our usage possibilities

That is surely not true when the interface is designed to accept enough
tweaking parameters in the various sub-commands.

> * increase code complexity
> * break the way the tool is used

* simplify its usage

Jan

[Andreas J. Reichel]

From: Andreas Reichel <andreas.r...@siemens.com>

Until now, providing no arguments caused bg_setenv to recalculate
the CRC of the latest environment and rewrite it.

This patch prevent it from doing this rather unintuitive action and
output a string to tell the user he must give further arguments
instead.

Signed-off-by: Andreas Reichel <andreas.r...@siemens.com>
---
tools/bg_setenv.c | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/tools/bg_setenv.c b/tools/bg_setenv.c
index 37f50ce..ca64b92 100644
--- a/tools/bg_setenv.c
+++ b/tools/bg_setenv.c
@@ -542,6 +542,14 @@ int main(int argc, char **argv)
bool write_mode = (bool)strstr(argv[0], "bg_setenv");
if (write_mode) {
argp = &argp_setenv;
+
+ if (argc < 2) {
+ printf("No task to perform. Please specify at least one"
+ " optional argument. See --help for further"
+ " information.\n");
+ return 1;
+ }
+
} else {
argp = &argp_printenv;
verbosity = true;
--
2.16.2

[Jan Kiszka]

Thanks, applied to next.

Jan