[PATCH v3 4/4] fs: remove explicit efi configuration dependency

Heinrich Schuchardt xypron.glpk at gmx.de
Wed Dec 20 10:07:39 CET 2023



Am 20. Dezember 2023 05:46:27 MEZ schrieb Simon Glass <sjg at chromium.org>:
>Hi Heinrich,
>
>On Mon, 18 Dec 2023 at 15:16, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>
>>
>>
>> Am 18. Dezember 2023 16:01:40 MEZ schrieb Simon Glass <sjg at chromium.org>:
>> >Hi AKASHI,
>> >
>> >On Sun, 17 Dec 2023 at 19:39, AKASHI Takahiro
>> ><takahiro.akashi at linaro.org> wrote:
>> >>
>> >> 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 at linaro.org>
>> >> ---
>> >>  fs/fs.c | 7 +++----
>> >>  1 file changed, 3 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/fs/fs.c b/fs/fs.c
>> >> index f33b85f92b61..82ee03b160e9 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] : "",
>> >> +                       (argc > 4) ? argv[4] : "", map_sysmem(addr, 0),
>> >> +                       len_read);
>> >
>> >As I understand it, this is setting the boot device so that (if it
>> >happens to be an efi application) it will know which device it came
>> >from. But this is a hack. For bootstd, the device is known as it loads
>> >the kernel.
>>
>> Please, consider what happens when the user interactively executes the load and bootefi command from the console.
>>
>> >
>> >Also it does not deal with memory allocation (nor can it).
>> >
>> >Where are we using the 'load' command to load a kernel? The distro
>> >scripts are deprecated.
>>
>> Some users use boot.scr scripts
>>
>>
>> >
>> >At some point this code should be removed. Is it too early for that?
>>
>> Yes, as long as we allow users to invoke the bootefi command with an address pointer.
>
>So how about we create the new path, with the info passed in as part
>of the bootefi call? Then we can remove the call from bootstd, at
>least.

Hello Simon,

Do you see a problem merging the current patch? Or are you talking about what we might do after this patch?

Best regards

Heinrich


More information about the U-Boot mailing list