Dear Ilias,
In message YCPVvmnF7TKxreE2@apalos.home you wrote:
In this case, "debug" would just be a sub-command of the "efi" command, with more sub-commands under efi (like bootmgr or such) following, same as we did for example with "env" (where many commands maintain backward compatibility, but here this was necessary because these have been in use forever):
env print -> printenv env save -> saveenv env set -> setenv
Yes, but it would still look a bit strange, because the efidebug command was overloaded in our case. So you could test capsules, set EFI bootmgr variables, dump EFI tables amongst other things. The saveenv & friends had a tightly defined scope already. So that would require a lot of code to keep the convention running, but since it's rarely used, I don't think it's worth the effort or the additional complexity (once again unless someone has a valid reason), hence my suggestion to define it properly while we still have time.
Indeed - if it was rarely used before, it makes a lot of sense to break combined functionality into separate subcommands (probably also with separate Kconfig options so you can select what you really need only).
Thanks!
Best regards,
Wolfgang Denk