From: Tom Rini <trini@konsulko.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
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: Thu, 26 Oct 2023 21:04:27 -0400 [thread overview]
Message-ID: <20231027010427.GS496310@bill-the-cat> (raw)
In-Reply-To: <ZTsLVnXoP5SBvFlz@octopus>
[-- Attachment #1: Type: text/plain, Size: 3147 bytes --]
On Fri, Oct 27, 2023 at 09:59:02AM +0900, AKASHI Takahiro wrote:
> 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.
Looking at all of the ways to solve this particular case again, OK, I
think we can go with #8, #10 and #11 as they are in this series, thanks
again.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2023-10-27 1:04 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
2023-10-27 1:04 ` Tom Rini [this message]
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=20231027010427.GS496310@bill-the-cat \
--to=trini@konsulko.com \
--cc=ilias.apalodimas@linaro.org \
--cc=jbx6244@gmail.com \
--cc=sjg@chromium.org \
--cc=takahiro.akashi@linaro.org \
--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 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.