On Wed, Oct 17, 2018 at 10:06:58AM +0200, Alexander Graf wrote: > > > On 17.10.18 09:32, AKASHI Takahiro wrote: > > This patch set is a collection of patches to enhance efi user interfaces > > /commands. It will help improve user experience on efi boot and make it > > more usable without edk2's shell utility. > > That's amazing, thanks a lot :) > > > Patch#1 to #4 are for efishell. > > Patch#5 and #6 are for bootmgr. > > > > Let's see how it works: > > => efishell boot add 1 SHELL mmc 0:1 /Shell.efi "" > > => efishell boot add 2 HELLO mmc 0:1 /hello.efi "" > > => efishell boot dump > > IMHO those 3 belong semantically to the "bootmgr" command. I can see how > "bootefi bootmgr add 1 SHELL ..." is terrible UX. But then again it's > not too much more to type than "efishell boot", right? ;) > > So at the end of the day, these should probably be > > => bootefi bootmgr add 1 SHELL mmc 0:1 /Shell.efi "" > => bootefi bootmgr add 2 HELLO mmc 0:1 /hello.efi "" > => bootefi bootmgr dump
To be frank, I hesitate to agree with you for several reasons. * Boot manager is a sort of boot loader application while adding/showing BootXXXX variables can be part of more generic system utility. (My interface here mimics uefi shell's bcfg command with slightly different syntax.) * In future, we may want to have another sub command, "driver," to support driver loading, namely DriverOrder/DriverXXXX. * Anyhow, we need another command for "setvar"( and "dumpvar"). > > Boot0001: > > attributes: A-- (0x00000001) > > label: SHELL > > file_path: > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,MBR,0x086246ba,0x800,0x40000)/\\Shell.efi > > data: > > Boot0002: > > attributes: A-- (0x00000001) > > label: HELLO > > file_path: > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,MBR,0x086246ba,0x800,0x40000)/\\hello.efi > > data: > > > > => efishell boot order 1 2 > > => efishell boot order > > Same thing here :). > > > 1: Boot0001: SHELL > > 2: Boot0002: HELLO > > > > => bootefi bootmgr -2 > > WARNING: booting without device tree > > Booting: HELLO > > ## Starting EFI application at 000000007db8b040 ... > > Hello, world! > > ## Application terminated, r = 0 > > > > => efishell setvar PlatformLang en <--- important! > > That one is slightly more complicated. How about we introduce a -e flag > to all the env operations? Then this would become > > => setenv -e PlatformLang en > > and you could print only EFI variables using > > => printenv -e > > maybe one day we could then also just implement partial variable storage > for UEFI variables: > > => saveenv -e > > which we could then reuse in the ExitBootServices() call to persist EFI > variables? I didn't get your point. Can you please elaborate it? > > => efishell bootmgr -1 or efishell bootmgr > > > > (shell ...) > > > > # The only drawback is that it can be confusing to type > > "bootefi ..." and "efi(shell) boot ..." :) > > Yes :). The compromise I can imagine is that efishell be also aliased to bootefi so that we can do: => efi(shell) boot add 1 ... => efi(shell) bootmgr -1 ( in my current syntax) Yet we still maintain an old/boot*-style interface: => bootefi bootmgr or <appl addr> Thanks, -Takahiro Akashi > > Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
