From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.88; helo=mga01.intel.com; envelope-from=jaben.carsey@intel.com; receiver=edk2-devel@lists.01.org Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5686721959CB2 for ; Wed, 5 Sep 2018 10:30:25 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Sep 2018 10:30:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,334,1531810800"; d="scan'208";a="81155983" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga003.jf.intel.com with ESMTP; 05 Sep 2018 10:30:24 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 5 Sep 2018 10:30:24 -0700 Received: from fmsmsx103.amr.corp.intel.com ([169.254.2.126]) by FMSMSX109.amr.corp.intel.com ([169.254.15.226]) with mapi id 14.03.0319.002; Wed, 5 Sep 2018 10:30:23 -0700 From: "Carsey, Jaben" To: Leif Lindholm CC: "edk2-devel@lists.01.org" , "Ni, Ruiyu" , Alexander Graf , Heinrich Schuchardt , AKASHI Takahiro , "Kinney, Michael D" , Andrew Fish , Laszlo Ersek Thread-Topic: portability of ShellPkg Thread-Index: AQHURT2FSII4bnoVI0+D2t3UnpHUkaTh8cUs Date: Wed, 5 Sep 2018 17:30:23 +0000 Message-ID: <9FF5C684-0DA6-45B0-93D8-F6358ACF1C7A@intel.com> References: <20180905172546.hxc2vqn6pgmr2zqs@bivouac.eciton.net> In-Reply-To: <20180905172546.hxc2vqn6pgmr2zqs@bivouac.eciton.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Subject: Re: portability of ShellPkg X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 17:30:25 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How does removing a lib from the components section affect the shell binary= output? Is the asset at compile time? Jaben > On Sep 5, 2018, at 10:26 AM, Leif Lindholm wro= te: >=20 > Hi all, >=20 > (This is partly a summary of discussions that have been held on IRC > and offline, with Alex Graf and Mike Kinney.) >=20 > 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. >=20 > 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. >=20 > 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 :) >=20 > 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): >=20 > 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/UefiShellDriver1CommandsLi= b.inf > ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1Commands= Lib.inf > - ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib= .inf > ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Commands= Lib.inf > ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2Commands= Lib.inf > =20 > 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. >=20 > Thoughts? >=20 > / > Leif