public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Tim Lewis <tim.lewis@insyde.com>
To: "Jim.Dailey@dell.com" <Jim.Dailey@dell.com>,
	"jaben.carsey@intel.com" <jaben.carsey@intel.com>,
	"ruiyu.ni@intel.com" <ruiyu.ni@intel.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: UEFI Shell Lib Constructor and Shell Parameters Protocol
Date: Wed, 5 Apr 2017 16:39:04 +0000	[thread overview]
Message-ID: <7236196A5DF6C040855A6D96F556A53F566D45@msmail.insydesw.com.tw> (raw)
In-Reply-To: <2acd9ee552f944598f9716c2f81780cc@ausx13mps335.AMER.DELL.COM>

There are "load options" that are passed to drivers (as a part of the EFI_LOADED_IMAGE_PROTOCOL), but there is no guarantee as to their format (binary data or ASCII string or UCS-2 string). It is possible for "load" to be modified to create this data and populate it between the calls to LoadImage() and StartImage() as the shell does, but that isn't spec.

Tim

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Jim.Dailey@dell.com
Sent: Wednesday, April 05, 2017 8:21 AM
To: jaben.carsey@intel.com; ruiyu.ni@intel.com
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol

Thanks, Jaben. That makes sense.

Now I see the real issue is with the "app" I ran across.  It is a driver, and it was trying to access command line args.  The driver crashed when it tried to access the command line, but it had been loaded in memory via the "load" command.

So, it seems "load" has no mechanism to pass command line arguments to a driver, and as a result, it apparently doesn't load the shell parameters protocol on the driver's handle, which caused the crash.

Regards,
Jim

-----Original Message-----
From: Carsey, Jaben [mailto:jaben.carsey@intel.com]
Sent: Wednesday, April 5, 2017 10:08 AM
To: Dailey, Jim <Jim_Dailey@Dell.com>; Ni, Ruiyu <ruiyu.ni@intel.com>
Cc: edk2-devel@lists.01.org
Subject: RE: UEFI Shell Lib Constructor and Shell Parameters Protocol

Jim,

That protocol must be installed on your applications own image handle for it to be valid.  Locating the protocol on some other image would result with finding the other image's command line parameters and the like...

-Jaben


> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of 
> Jim.Dailey@dell.com
> Sent: Wednesday, April 05, 2017 7:07 AM
> To: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ruiyu 
> <ruiyu.ni@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] UEFI Shell Lib Constructor and Shell Parameters 
> Protocol
> Importance: High
> 
> 
> A question or two for all shell experts:
> 
> In the UEFI Shell Lib constructor code, if the Shell protocol cannot 
> be opened, then an attempt is made to locate it before "giving up".
> 
> However, if the Shell parameters protocol cannot be opened, no attempt 
> is made to locate it---the code simply leaves the parameters protocol 
> pointer set to NULL. Can anyone explain why this is?
> 
> I came across an app that crashes because of this behavior, but if I 
> add code to try and locate the parameters protocol, then the app works 
> as designed WRT accessing command line parameters.  Is there some 
> lurking issue if an attempt to locate the parameters protocol is made 
> and is successful?
> 
> Thanks,
> Jim
> 
> -------
> Here is the relevant code:
> 
> EFI_STATUS
> ShellLibConstructorWorker (
>   IN EFI_HANDLE        ImageHandle,
>   IN EFI_SYSTEM_TABLE  *SystemTable
>   )
> {
>   EFI_STATUS  Status;
> 
>   //
>   // UEFI 2.0 shell interfaces (used preferentially)
>   //
>   Status = gBS->OpenProtocol(
>     ImageHandle,
>     &gEfiShellProtocolGuid,
>     (VOID **)&gEfiShellProtocol,
>     ImageHandle,
>     NULL,
>     EFI_OPEN_PROTOCOL_GET_PROTOCOL
>    );
>   if (EFI_ERROR(Status)) {
>     //
>     // Search for the shell protocol
>     //
>     Status = gBS->LocateProtocol(
>       &gEfiShellProtocolGuid,
>       NULL,
>       (VOID **)&gEfiShellProtocol
>      );
>     if (EFI_ERROR(Status)) {
>       gEfiShellProtocol = NULL;
>     }
>   }
>   Status = gBS->OpenProtocol(
>     ImageHandle,
>     &gEfiShellParametersProtocolGuid,
>     (VOID **)&gEfiShellParametersProtocol,
>     ImageHandle,
>     NULL,
>     EFI_OPEN_PROTOCOL_GET_PROTOCOL
>    );
>   if (EFI_ERROR(Status)) {
> #if 1 // _Dell_ : Search for the parameters protocol too!
>     //
>     // Search for the shell parameters protocol
>     //
>     Status = gBS->LocateProtocol(
>       &gEfiShellParametersProtocolGuid,
>       NULL,
>       (VOID **)&gEfiShellParametersProtocol
>      );
>     if (EFI_ERROR(Status)) {
>       gEfiShellParametersProtocol = NULL;
>     }
> #else
>     gEfiShellParametersProtocol = NULL; #endif
>   }
> ...
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


      parent reply	other threads:[~2017-04-05 16:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05 14:07 UEFI Shell Lib Constructor and Shell Parameters Protocol Jim.Dailey
2017-04-05 15:08 ` Carsey, Jaben
2017-04-05 15:21   ` Jim.Dailey
2017-04-05 16:08     ` Carsey, Jaben
2017-04-05 16:39     ` Tim Lewis [this message]

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-list 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=7236196A5DF6C040855A6D96F556A53F566D45@msmail.insydesw.com.tw \
    --to=devel@edk2.groups.io \
    /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