All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.