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
prev parent 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