* [U-Boot] efi_loader: LoadOptions (bootargs)
@ 2019-08-22 9:03 AKASHI Takahiro
2019-08-22 17:53 ` Heinrich Schuchardt
0 siblings, 1 reply; 6+ messages in thread
From: AKASHI Takahiro @ 2019-08-22 9:03 UTC (permalink / raw)
To: u-boot
Heinrich,
I'm now wondering whether LoadedImage's LoadOptions, which comes
from "bootargs" variable, should contain a command(application) name
as a first argument or not.
When I tried some efi application (efitools), I found that it expected
so. For example, efitools' UpdateVars.efi takes
Usage: UpdateVars.efi: [-g guid] [-a] [-e] [-b] var file
and I had to passed arguments by specifying "foo db DB.auth" for
"bootargs" where foo makes no sense.
What do you think about this issue?
Thanks,
-Takahiro Akashi
^ permalink raw reply [flat|nested] 6+ messages in thread* [U-Boot] efi_loader: LoadOptions (bootargs) 2019-08-22 9:03 [U-Boot] efi_loader: LoadOptions (bootargs) AKASHI Takahiro @ 2019-08-22 17:53 ` Heinrich Schuchardt 2019-08-22 23:42 ` AKASHI Takahiro 0 siblings, 1 reply; 6+ messages in thread From: Heinrich Schuchardt @ 2019-08-22 17:53 UTC (permalink / raw) To: u-boot On 8/22/19 11:03 AM, AKASHI Takahiro wrote: > Heinrich, > > I'm now wondering whether LoadedImage's LoadOptions, which comes > from "bootargs" variable, should contain a command(application) name > as a first argument or not. > > When I tried some efi application (efitools), I found that it expected > so. For example, efitools' UpdateVars.efi takes > Usage: UpdateVars.efi: [-g guid] [-a] [-e] [-b] var file > > and I had to passed arguments by specifying "foo db DB.auth" for > "bootargs" where foo makes no sense. > > What do you think about this issue? Do you relate to https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git? This style of parsing LoadOptions is defined by the EFI shell. See function ParseCommandLineToArgs() in ShellPkg/Application/Shell/ShellParametersProtocol.c. If UpdateVars.efi would work differently it could not be launched via the shell. Best regards Heinrich ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] efi_loader: LoadOptions (bootargs) 2019-08-22 17:53 ` Heinrich Schuchardt @ 2019-08-22 23:42 ` AKASHI Takahiro 2019-09-11 6:14 ` AKASHI Takahiro 0 siblings, 1 reply; 6+ messages in thread From: AKASHI Takahiro @ 2019-08-22 23:42 UTC (permalink / raw) To: u-boot On Thu, Aug 22, 2019 at 07:53:46PM +0200, Heinrich Schuchardt wrote: > On 8/22/19 11:03 AM, AKASHI Takahiro wrote: > >Heinrich, > > > >I'm now wondering whether LoadedImage's LoadOptions, which comes > >from "bootargs" variable, should contain a command(application) name > >as a first argument or not. > > > >When I tried some efi application (efitools), I found that it expected > >so. For example, efitools' UpdateVars.efi takes > > Usage: UpdateVars.efi: [-g guid] [-a] [-e] [-b] var file > > > >and I had to passed arguments by specifying "foo db DB.auth" for > >"bootargs" where foo makes no sense. > > > >What do you think about this issue? > > Do you relate to > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git? Yes. > This style of parsing LoadOptions is defined by the EFI shell. See > function ParseCommandLineToArgs() in > ShellPkg/Application/Shell/ShellParametersProtocol.c. So do you mean that Shell.efi is responsible for adding a command name to LoadOptions (or bootargs) as a first parameter or that LoadOptions is solely for Shell environment? If so, should we do the same thing at bootefi? > If UpdateVars.efi would work differently it could not be launched via > the shell. Well, I'm trying to run UpdateVars.efi in a standalone way by invoking it directly from bootefi/bootmgr and it obviously fails due to this issue. Thanks, -Takashiro Akashi > Best regards > > Heinrich ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] efi_loader: LoadOptions (bootargs) 2019-08-22 23:42 ` AKASHI Takahiro @ 2019-09-11 6:14 ` AKASHI Takahiro 2019-09-11 17:39 ` Heinrich Schuchardt 0 siblings, 1 reply; 6+ messages in thread From: AKASHI Takahiro @ 2019-09-11 6:14 UTC (permalink / raw) To: u-boot Heinrich, On Fri, Aug 23, 2019 at 08:42:27AM +0900, AKASHI Takahiro wrote: > On Thu, Aug 22, 2019 at 07:53:46PM +0200, Heinrich Schuchardt wrote: > > On 8/22/19 11:03 AM, AKASHI Takahiro wrote: > > >Heinrich, > > > > > >I'm now wondering whether LoadedImage's LoadOptions, which comes > > >from "bootargs" variable, should contain a command(application) name > > >as a first argument or not. > > > > > >When I tried some efi application (efitools), I found that it expected > > >so. For example, efitools' UpdateVars.efi takes > > > Usage: UpdateVars.efi: [-g guid] [-a] [-e] [-b] var file > > > > > >and I had to passed arguments by specifying "foo db DB.auth" for > > >"bootargs" where foo makes no sense. > > > > > >What do you think about this issue? > > > > Do you relate to > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git? > > Yes. > > > This style of parsing LoadOptions is defined by the EFI shell. See > > function ParseCommandLineToArgs() in > > ShellPkg/Application/Shell/ShellParametersProtocol.c. > > So do you mean that Shell.efi is responsible for adding a command name > to LoadOptions (or bootargs) as a first parameter or that LoadOptions > is solely for Shell environment? > > If so, should we do the same thing at bootefi? Any comment? -Takahiro Akashi > > If UpdateVars.efi would work differently it could not be launched via > > the shell. > > Well, I'm trying to run UpdateVars.efi in a standalone way > by invoking it directly from bootefi/bootmgr and it obviously fails > due to this issue. > > Thanks, > -Takashiro Akashi > > > > Best regards > > > > Heinrich ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] efi_loader: LoadOptions (bootargs) 2019-09-11 6:14 ` AKASHI Takahiro @ 2019-09-11 17:39 ` Heinrich Schuchardt 2019-09-12 0:31 ` AKASHI Takahiro 0 siblings, 1 reply; 6+ messages in thread From: Heinrich Schuchardt @ 2019-09-11 17:39 UTC (permalink / raw) To: u-boot On 9/11/19 8:14 AM, AKASHI Takahiro wrote: > Heinrich, > > On Fri, Aug 23, 2019 at 08:42:27AM +0900, AKASHI Takahiro wrote: >> On Thu, Aug 22, 2019 at 07:53:46PM +0200, Heinrich Schuchardt wrote: >>> On 8/22/19 11:03 AM, AKASHI Takahiro wrote: >>>> Heinrich, >>>> >>>> I'm now wondering whether LoadedImage's LoadOptions, which comes >>> >from "bootargs" variable, should contain a command(application) name >>>> as a first argument or not. >>>> >>>> When I tried some efi application (efitools), I found that it expected >>>> so. For example, efitools' UpdateVars.efi takes >>>> Usage: UpdateVars.efi: [-g guid] [-a] [-e] [-b] var file >>>> >>>> and I had to passed arguments by specifying "foo db DB.auth" for >>>> "bootargs" where foo makes no sense. >>>> >>>> What do you think about this issue? >>> >>> Do you relate to >>> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git? >> >> Yes. >> >>> This style of parsing LoadOptions is defined by the EFI shell. See >>> function ParseCommandLineToArgs() in >>> ShellPkg/Application/Shell/ShellParametersProtocol.c. >> >> So do you mean that Shell.efi is responsible for adding a command name >> to LoadOptions (or bootargs) as a first parameter or that LoadOptions >> is solely for Shell environment? LoadOptions are used to communicate with any EFI binary including the Linux kernels. Inside the EFI shell Shell.efi takes care of passing the executable name as a first parameter. If a user chooses to call an EFI binary which expects its own name as first parameter via bootefi, the user should simply add it to LoadOptions via 'setenv bootargs'. I would not change anything in bootefi. Otherwise you start passing 'vmlinux' or 'grubaa64.efi' as command line arguments to Linux. Best regards Heinrich >> >> If so, should we do the same thing at bootefi? > > Any comment? > > -Takahiro Akashi > > >>> If UpdateVars.efi would work differently it could not be launched via >>> the shell. >> >> Well, I'm trying to run UpdateVars.efi in a standalone way >> by invoking it directly from bootefi/bootmgr and it obviously fails >> due to this issue. >> >> Thanks, >> -Takashiro Akashi >> >> >>> Best regards >>> >>> Heinrich > ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] efi_loader: LoadOptions (bootargs) 2019-09-11 17:39 ` Heinrich Schuchardt @ 2019-09-12 0:31 ` AKASHI Takahiro 0 siblings, 0 replies; 6+ messages in thread From: AKASHI Takahiro @ 2019-09-12 0:31 UTC (permalink / raw) To: u-boot On Wed, Sep 11, 2019 at 07:39:07PM +0200, Heinrich Schuchardt wrote: > On 9/11/19 8:14 AM, AKASHI Takahiro wrote: > >Heinrich, > > > >On Fri, Aug 23, 2019 at 08:42:27AM +0900, AKASHI Takahiro wrote: > >>On Thu, Aug 22, 2019 at 07:53:46PM +0200, Heinrich Schuchardt wrote: > >>>On 8/22/19 11:03 AM, AKASHI Takahiro wrote: > >>>>Heinrich, > >>>> > >>>>I'm now wondering whether LoadedImage's LoadOptions, which comes > >>>>from "bootargs" variable, should contain a command(application) name > >>>>as a first argument or not. > >>>> > >>>>When I tried some efi application (efitools), I found that it expected > >>>>so. For example, efitools' UpdateVars.efi takes > >>>> Usage: UpdateVars.efi: [-g guid] [-a] [-e] [-b] var file > >>>> > >>>>and I had to passed arguments by specifying "foo db DB.auth" for > >>>>"bootargs" where foo makes no sense. > >>>> > >>>>What do you think about this issue? > >>> > >>>Do you relate to > >>>https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git? > >> > >>Yes. > >> > >>>This style of parsing LoadOptions is defined by the EFI shell. See > >>>function ParseCommandLineToArgs() in > >>>ShellPkg/Application/Shell/ShellParametersProtocol.c. > >> > >>So do you mean that Shell.efi is responsible for adding a command name > >>to LoadOptions (or bootargs) as a first parameter or that LoadOptions > >>is solely for Shell environment? > > LoadOptions are used to communicate with any EFI binary including the > Linux kernels. Inside the EFI shell Shell.efi takes care of passing the > executable name as a first parameter. > > If a user chooses to call an EFI binary which expects its own name as > first parameter via bootefi, the user should simply add it to > LoadOptions via 'setenv bootargs'. Right, but my concern is that a user normally doesn't care/know if an application expects that it would be invoked from Shell or with Shell-style arguments. > I would not change anything in bootefi. Otherwise you start passing > 'vmlinux' or 'grubaa64.efi' as command line arguments to Linux. How can users distinguish vmlinux or whatever else from other apps that would expect Shell-style arguments in general? -Takahiro Akashi > Best regards > > Heinrich > > >> > >>If so, should we do the same thing at bootefi? > > > >Any comment? > > > >-Takahiro Akashi > > > > > >>>If UpdateVars.efi would work differently it could not be launched via > >>>the shell. > >> > >>Well, I'm trying to run UpdateVars.efi in a standalone way > >>by invoking it directly from bootefi/bootmgr and it obviously fails > >>due to this issue. > >> > >>Thanks, > >>-Takashiro Akashi > >> > >> > >>>Best regards > >>> > >>>Heinrich > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-09-12 0:31 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-08-22 9:03 [U-Boot] efi_loader: LoadOptions (bootargs) AKASHI Takahiro 2019-08-22 17:53 ` Heinrich Schuchardt 2019-08-22 23:42 ` AKASHI Takahiro 2019-09-11 6:14 ` AKASHI Takahiro 2019-09-11 17:39 ` Heinrich Schuchardt 2019-09-12 0:31 ` AKASHI Takahiro
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox