public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Tom Rini <trini@konsulko.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
	sjg@chromium.org, ilias.apalodimas@linaro.org, jbx6244@gmail.com,
	u-boot@lists.denx.de
Subject: Re: [RFC 11/13] fs: remove explicit efi configuration dependency
Date: Fri, 27 Oct 2023 09:59:02 +0900	[thread overview]
Message-ID: <ZTsLVnXoP5SBvFlz@octopus> (raw)
In-Reply-To: <20231026124752.GF496310@bill-the-cat>

[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]

On Thu, Oct 26, 2023 at 08:47:52AM -0400, Tom Rini wrote:
> On Thu, Oct 26, 2023 at 05:48:30PM +0900, AKASHI Takahiro wrote:
> > On Thu, Oct 26, 2023 at 09:58:53AM +0200, Heinrich Schuchardt wrote:
> > > 
> > > 
> > > Am 26. Oktober 2023 07:30:50 MESZ schrieb AKASHI Takahiro <takahiro.akashi@linaro.org>:
> > > >Now it is clear that the feature actually depends on efi interfaces,
> > > >not "bootefi" command. efi_set_bootdev() will automatically be nullified
> > > >if necessary efi component is disabled.
> > > >
> > > >Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > >---
> > > > fs/fs.c | 7 +++----
> > > > 1 file changed, 3 insertions(+), 4 deletions(-)
> > > >
> > > >diff --git a/fs/fs.c b/fs/fs.c
> > > >index 4cb4310c9cc2..70cdb594c4c8 100644
> > > >--- a/fs/fs.c
> > > >+++ b/fs/fs.c
> > > >@@ -791,10 +791,9 @@ int do_load(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[],
> > > > 		return 1;
> > > > 	}
> > > > 
> > > >-	if (IS_ENABLED(CONFIG_CMD_BOOTEFI))
> > > >-		efi_set_bootdev(argv[1], (argc > 2) ? argv[2] : "",
> > > >-				(argc > 4) ? argv[4] : "", map_sysmem(addr, 0),
> > > >-				len_read);
> > > >+	efi_set_bootdev(argv[1], (argc > 2) ? argv[2] : "",
> > > 
> > > This function should not exist for CONFIG_EFI_LOADER=n. There are other places where the function is invoked. Please, review all of them.
> > 
> > Please go through the whole patch set, especially patch#8
> > "efi_loader: split unrelated code from efi_bootmgr.c".
> > 
> > efi_[set|clear]_bootdev() will be nullified if not necessary.
> 
> In this case I think what we have here today is more readable / clearer.
> We don't need empty functions as we can either do like this section of
> the code does today or the linker will discard things correctly as it's
> a case of funcB() calls funcA() and nothing calls funcB() so it will be
> discarded. I don't know without digging through the series more what the
> correct IS_ENABLED() guard should be here (and then also in patch #10).

If I correctly understand your question, it is my point in this commit.

I believe that a caller should not be bothered by thinking of what efi CONFIG
be used for the guard. All that should be done is to just put a right hook
(efi_set_bootdev() in this case) at a right place as a caller (do_load()
in this case) is apparently irrelevant to UEFI subsystem.
Hereafter, whatever rework may be done on UEFI side (like my refactoring
here), other code won't need to be modified.

If you want to rely on an intelligent linker behavior, I would suggest
another approach, modifying efi_set_bootdev() as follows;

efi_set_bootdev(...)
{
    if (!IS_ENABLED(EFI_BINARY_EXEC))
        return;
    ...
}

I hope it would also work.

-Takahiro Akashi

> 
> -- 
> Tom



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2023-10-27  0:59 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-26  5:30 [RFC 00/13] cmd: bootefi: refactor the code for bootmgr AKASHI Takahiro
2023-10-26  5:30 ` [RFC 01/13] cmd: bootefi: unfold do_bootefi_image() AKASHI Takahiro
2023-10-26 11:01   ` Heinrich Schuchardt
2023-10-27  0:25     ` AKASHI Takahiro
2023-10-27  1:00       ` Tom Rini
2023-10-27 12:23         ` Ilias Apalodimas
2023-10-30  0:34           ` AKASHI Takahiro
2023-10-26  5:30 ` [RFC 02/13] cmd: bootefi: re-organize do_bootefi_image() AKASHI Takahiro
2023-10-26 10:44   ` Heinrich Schuchardt
2023-10-26 12:47     ` Tom Rini
2023-10-27  0:35     ` AKASHI Takahiro
2023-10-26  5:30 ` [RFC 03/13] cmd: bootefi: carve out EFI boot manager interface AKASHI Takahiro
2023-10-26  5:30 ` [RFC 04/13] cmd: bootefi: carve out binary execution interface AKASHI Takahiro
2023-10-26  5:30 ` [RFC 05/13] cmd: bootefi: move library interfaces under lib/efi_loader AKASHI Takahiro
2023-10-26  5:30 ` [RFC 06/13] cmd: efidebug: ease efi configuration dependency AKASHI Takahiro
2023-10-26  5:30 ` [RFC 07/13] bootmeth: use efi_loader interfaces instead of bootefi command AKASHI Takahiro
2023-10-26  5:30 ` [RFC 08/13] efi_loader: split unrelated code from efi_bootmgr.c AKASHI Takahiro
2023-10-26  5:30 ` [RFC 09/13] efi_loader: rename BOOTEFI_BOOTMGR to EFI_BOOTMGR AKASHI Takahiro
2023-10-26  5:30 ` [RFC 10/13] net: tftp: remove explicit efi configuration dependency AKASHI Takahiro
2023-10-26  5:30 ` [RFC 11/13] fs: " AKASHI Takahiro
2023-10-26  7:58   ` Heinrich Schuchardt
2023-10-26  8:48     ` AKASHI Takahiro
2023-10-26 12:47       ` Tom Rini
2023-10-27  0:59         ` AKASHI Takahiro [this message]
2023-10-27  1:04           ` Tom Rini
2023-10-26  5:30 ` [RFC 12/13] lib: uuid: move CONFIG_RANDOM_UUID AKASHI Takahiro
2023-10-26 12:47   ` Tom Rini
2023-10-27 12:24   ` Ilias Apalodimas
2023-10-26  5:30 ` [RFC 13/13] block: rkmtd: select CONFIG_RANDOM_UUID explicitly AKASHI Takahiro
2023-10-26 12:47   ` Tom Rini
2023-10-26 12:47 ` [RFC 00/13] cmd: bootefi: refactor the code for bootmgr Tom Rini

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=ZTsLVnXoP5SBvFlz@octopus \
    --to=takahiro.akashi@linaro.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jbx6244@gmail.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.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