[U-Boot] [PATCH 6/6] efi_loader: bootmgr: run an EFI application of a given load option

[AKASHI Takahiro]

On Mon, Oct 22, 2018 at 07:58:29AM +0100, Alexander Graf wrote:
> 
> 
> On 22.10.18 06:37, AKASHI Takahiro wrote:
> > On Thu, Oct 18, 2018 at 10:46:36AM +0200, Alexander Graf wrote:
> >>
> >>
> >> On 18.10.18 07:48, AKASHI Takahiro wrote:
> >>> On Wed, Oct 17, 2018 at 10:43:22AM +0200, Alexander Graf wrote:
> >>>>
> >>>>
> >>>> On 17.10.18 09:32, AKASHI Takahiro wrote:
> >>>>> With this patch applied, we will be able to selectively execute
> >>>>> an EFI application by specifying a load option, say "-1" for Boot0001,
> >>>>> "-2" for Boot0002 and so on.
> >>>>>
> >>>>>   => bootefi bootmgr -1 <fdt addr>
> >>>>
> >>>> I don't think -1 is very good user experience :). How about
> >>>>   => bootefi bootmgr Boot0001 <fdt addr>
> >>>
> >>> It looks like u-boot's run command with six more characters!
> >>> How about this:
> >>>
> >>>  => bootefi bootmgr #1 <fdt addr>
> >>
> >> So what is the problem with making it Boot0001? That way at least the
> >> variable name is consistent across the board ;).
> > 
> > More typing!
> > 
> >>> or allowing "-" as empty fdt,
> >>>
> >>>  => bootefi bootmgr - 1
> > 
> > (Please notice that this is NOT "-1.")
> > I also like this one as it maintains upward-compatibility:
> >     bootefi bootmgr [<fdt addr> [<boot id>]]
> > 
> >>> Otherwise, a new sub command?
> >>>
> >>>  => bootefi run 1, or
> >>>  => efi(shell) run 1
> > 
> > Well, if you stick to "setenv -e"-like syntax, how about
> >     => run -e Boot0001
> > 
> > Given that "run" takes an environment variable, this syntax
> > is perfectly fit to U-boot, isn't it?
> 
> Ooooh, that is an amazing suggestion! And "run -e" without an explicit
> target could just invoke efibootmgr directly, looping through the BootOrder.

We agree here :)

> > 
> >>> # Discussing UI is a fun or mess.
> > 
> > # I hope that this is not fruitless discussion.
> > 
> >> Yeah :(. What we really need would be that "bootefi bootmgr" becomes
> >> "efiboot". But that would be even more confusing ;).
> > 
> > So I think that we should not add anything more to "bootefi bootmgr"
> > to extend functionality.
> > 
> >> So the whole rationale of why "bootefi" is the way it is today is that
> >> it's trying to lean on the existing "bootm", "booti", "bootz" etc syntax
> >> as much as it can. In other words, it's trying to fit into the U-Boot
> >> ecosystem much rather than the existing edk2 one.
> > 
> > IMO, "boot*" variants are already a mess.
> > 
> >> I would like to keep following that path going forward. Whenever there
> >> is an option between "U-Boot like" and "edk2 like" I would always opt
> >> for the "U-Boot like" user experience, because if they want edk2 they
> >> may as well use edk2 ;).
> > 
> > Well, BootXXXX is quite UEFI-specific and people who are not familiar
> > with UEFI need to consult UEFI specification anyway and this means, to me,
> > that UEFI shell's similarity would be favorable.
> > (See "setvar" syntax, not mine but UEFI shell's, which can be
> > quite different and complicated.)
> 
> Well my thinking there is that if someone likes the UEFI Shell, they may
> as well just run it :).

My aim here is to provide poor man's uefi shell!
For example, I think there are a few useful commands to be supported:
* devices
* devtree
* dh
* (dis)connect
* drivers
* memmap
* unload
They must be useful even now for debugging and understanding
internal status of UEFI environment.
# Please note that some of those commands in edk2's shell
  will still cause a panic.

That's is why I want to have efi(shell) command.

Thanks,
-Takahiro Akashi

> 
> Alex
> 
> > 
> > Does anybody else have any opinions?
> > 
> > Thanks,
> > -Takahiro Akashi
> > 
> >>
> >> Alex