public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	u-boot@lists.denx.de,
	Masahisa Kojima <masahisa.kojima@linaro.org>,
	Alexander Graf <agraf@csgraf.de>
Subject: Re: [RFC 1/1] efi_loader: rename 'efidebug boot' 'bootefi'
Date: Mon, 17 Jan 2022 11:59:02 +0200	[thread overview]
Message-ID: <YeU95kEZxFDUilly@hades> (raw)
In-Reply-To: <6f5fcac5-4ae3-c401-0121-db7f80197ad5@canonical.com>

Hi Heinrich

On Mon, Jan 17, 2022 at 10:25:01AM +0100, Heinrich Schuchardt wrote:
> On 1/17/22 08:58, Ilias Apalodimas wrote:
> > On Mon, Jan 17, 2022 at 10:16:51AM +0900, AKASHI Takahiro wrote:
> > > On Sat, Jan 15, 2022 at 01:49:07AM +0100, Heinrich Schuchardt wrote:
> > > > The efidebug command was conceived for testing purposes.
> > > 
> > > Well, I initially implemented the command as an alternative of
> > > "EFI shell" as the shell was not able to run on EFI U-Boot at that time.
> > > 
> > > > The manipulation of boot options does better fit to the bootefi command
> > > > that is used to invoke the boot manager.
> > > 
> > > I believe that it would be best to have those two features
> > > in separate commands(/applications) since the bootefi/bootmgr be focused
> > > on booting EFI images while efidebug/EFI shell provides a kind of
> > > user interfaces for manipulating the system.
> > > 
> > > *If* you dare to move the code to bootefi/bootmgr, I'd ask you to honor
> > > and add my copyright to the file as "efidebug boot" feature is a core part
> > > of efidebug. Or export sub-command functions from efidebug.c and import
> > > them in bootefi.c.
> > 
> > I think renaming the efidebug command is overall good idea,  since it does
> > way more that debugging.  OTOH I think moving it to 'bootefi' is the wrong
> > way to go.  I'd be much happier if we kept bootefi for booting related
> > commands and purposes and rename 'efidebug' to 'efi'.  Then we could split
> > off the debug related commands to 'efi debug xxxxxxxxx' and put it under a
> > Kconfig option.
> 
> For me the important thing is that we should be able enable boot options
> related commands without the rest of efidebug to limit code size increase.
> 

Yes,  but isn't that doable by what I suggested?

> efidebug boot is only needed if CONFIG_CMD_BOOTEFI_BOOTMGR=y.
> 
> efidebug capsule is only needed for testing on QEMU, Sandbox if capsules are
> enabled. I can't see that a normal user would ever use it.
> 
> efidebug devices, drivers, dh, images, memmap, query, tables is only needed
> for debugging and should be disabled by default.


Yes,  those would be the options we could place under a new Kconfig, which enables
debugging capabilities on the command

Cheers
/Ilias
> 
> efidebug test is only needed on the Sandbox.
> 
> All commands lack documentation in /doc/usage/
> 
> Best regards
> 
> Heinrich

      reply	other threads:[~2022-01-17  9:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-15  0:49 [RFC 1/1] efi_loader: rename 'efidebug boot' 'bootefi' Heinrich Schuchardt
2022-01-17  1:16 ` AKASHI Takahiro
2022-01-17  7:58   ` Ilias Apalodimas
2022-01-17  9:25     ` Heinrich Schuchardt
2022-01-17  9:59       ` Ilias Apalodimas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YeU95kEZxFDUilly@hades \
    --to=ilias.apalodimas@linaro.org \
    --cc=agraf@csgraf.de \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=masahisa.kojima@linaro.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox