From mboxrd@z Thu Jan  1 00:00:00 1970
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
Date: Mon, 3 Dec 2018 16:02:18 +0900
Subject: [U-Boot] [PATCH v2 05/14] cmd: efishell: add devices command
In-Reply-To: <89822a49-e099-5bb4-1bbd-268518bc3064@suse.de>
References: <20181105090653.7409-1-takahiro.akashi@linaro.org>
 <20181105090653.7409-6-takahiro.akashi@linaro.org>
 <89822a49-e099-5bb4-1bbd-268518bc3064@suse.de>
Message-ID: <20181203070217.GD28995@linaro.org>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Mon, Dec 03, 2018 at 12:46:20AM +0100, Alexander Graf wrote:
> 
> 
> On 05.11.18 10:06, AKASHI Takahiro wrote:
> > "devices" command prints all the uefi variables on the system.
> > => efishell devices
> > Device Name
> > ============================================
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/\
> > 				HD(2,MBR,0x086246ba,0x40800,0x3f800)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/\
> > 				HD(1,MBR,0x086246ba,0x800,0x40000)
> > 
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > ---
> >  cmd/efishell.c | 88 +++++++++++++++++++++++++++++++++++++++++++++++++-
> >  1 file changed, 87 insertions(+), 1 deletion(-)
> > 
> > diff --git a/cmd/efishell.c b/cmd/efishell.c
> > index abc8216c7bd6..f4fa3fdf28a7 100644
> > --- a/cmd/efishell.c
> > +++ b/cmd/efishell.c
> > @@ -21,6 +21,8 @@
> >  
> >  DECLARE_GLOBAL_DATA_PTR;
> >  
> > +static const struct efi_boot_services *bs;
> 
> Why do you need a local copy of this?

Good point. It's because I followed the way boot manager does :)

I think that it would be good to do so since either boot manager or
efishell should ultimately be an independent efi application
in its nature.

What do you think?

FYI, one of the reasons why efishell cannot be an application
is that we lack an runtime service interface of GetNextVariableName()
which can be used to enumerate variables in dumpvar sub-command.

I also have a patch for adding GetNextVariableName() in my local dev branch.
I intend to post this patch along with capsule-on-disk support,
but I may be able to submit it separately if you like.

Thanks,
-Takahiro Akashi

> 
> Alex