[U-Boot] efi_loader: LoadOptions (bootargs)
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
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
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
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
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
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
participants (2)
-
AKASHI Takahiro -
Heinrich Schuchardt