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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
