Re: portability of ShellPkg

[Leif Lindholm <leif.lindholm@linaro.org>]

On Wed, Sep 05, 2018 at 05:30:23PM +0000, Carsey, Jaben wrote:
> How does removing a lib from the components section affect the shell binary output?

Maybe it doesn't and I'm barking up the wrong tree? Unfortunately,
the only thing that means is we don't have a trivial workaround.

/
    Leif

> Is the asset at compile time?
> 
> Jaben
> 
> > On Sep 5, 2018, at 10:26 AM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > 
> > Hi all,
> > 
> > (This is partly a summary of discussions that have been held on IRC
> > and offline, with Alex Graf and Mike Kinney.)
> > 
> > The UEFI Shell, as produced by the contents of ShellPkg, is needed for
> > running the UEFI SCT. This has never been problematic before - but now
> > we are starting to run SCT on the U-Boot implementation of the UEFI
> > interfaces, certain implicit assumptions may need to be made explicit,
> > and perhaps reevaluated.
> > 
> > My feeling is the following:
> > - The MinUefiShell variant should be sufficient to run SCT.
> > - The UEFI Shell as provided by ShellPkg (any flavour) should run on
> >  any valid UEFI implementation. Where underlying functionality is
> >  missing for certain commands, those commands should be
> >  degraded/disabled to let remaining commands function.
> > 
> > Ideally, I would like to see a Readme.md in ShellPkg, basically
> > providing a mission statement. I could write one, but I expect the
> > people who actually maintain it would be better suited :)
> > 
> > We currently have an issue with running the shell on U-Boot because
> > even MinUefiShell pulls in UefiShellDebug1CommandsLib.inf. This
> > appears to be inadvertent, since it is also included a few lines
> > further down inside an !ifndef $(NO_SHELL_PROFILES) guard.
> > So I would propose the following patch (and can send it out properly
> > if the maintainers agree):
> > 
> > diff --git a/ShellPkg/ShellPkg.dsc b/ShellPkg/ShellPkg.dsc
> > index 59dd07e0ae..c852abd3f7 100644
> > --- a/ShellPkg/ShellPkg.dsc
> > +++ b/ShellPkg/ShellPkg.dsc
> > @@ -101,7 +101,6 @@ [Components]
> >   ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
> >   ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
> >   ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
> > -  ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
> >   ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
> >   ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
> >          
> > The reason this causes a problem is because this module has a
> > dependency on HobLib, which ASSERTS if it does not find any HOBs lying
> > around. Since HOBs are a PI concept rather than a UEFI concept,
> > ideally we would not terminate the shell if they are missing. However,
> > since the HobLib is generic to EDK2, we also shouldn't just go
> > stripping ASSERTs out of it. The above patch gives us a way of
> > unblocking the SCT on U-Boot UEFI while we consider what to do about
> > the bigger question.
> > 
> > Thoughts?
> > 
> > /
> >    Leif