On 10/05/16 22:44, Tim Lewis wrote: > Jaben -- > > In which cases would you have the Shell protocol present and not have the > Unicode Collation protocol?
That's exactly the question! According to the spec, at least if the system cannot boot from a disk device, then the collation protocol need not be present. > By my count, the Shell itself cannot function without it (see > ProcessCommandLine()). In which case though I don't understand why Daniil experiences this change (= commit 583448b441650) as a regression on Juno. If the shell couldn't function without the collation protocol even before commit 583448b441650, then the shell must never have run on Juno -- because it appears to lack collation -- and then this change cannot be a regression. Thanks Laszlo > > Tim > > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Carsey, Jaben > Sent: Wednesday, October 05, 2016 1:35 PM > To: Shah, Tapan <tapands...@hpe.com>; Laszlo Ersek <ler...@redhat.com>; > Andrew Fish <af...@apple.com>; Daniil Egranov <daniil.egra...@arm.com> > Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel-01 > <edk2-de...@ml01.01.org>; Leif Lindholm <leif.lindh...@arm.com> > Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on > the Reference Platform > > That should work. We also need to initialize the variable to NULL in the > constructor. > > Do we need to be case insensitive for this? Can we use memcmp instead of the > prototol? > > -Jaben > >> -----Original Message----- >> From: Shah, Tapan [mailto:tapands...@hpe.com] >> Sent: Wednesday, October 05, 2016 1:25 PM >> To: Laszlo Ersek <ler...@redhat.com>; Andrew Fish <af...@apple.com>; >> Daniil Egranov <daniil.egra...@arm.com> >> Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel-01 <edk2- >> de...@ml01.01.org>; Leif Lindholm <leif.lindh...@arm.com> >> Subject: RE: [edk2] Assert in ShellPkg with latest tianocore edk2 >> source on the Reference Platform >> Importance: High >> >> How about moving protocol locate from constructor to the actual >> function level and returning an error if it fails to locate (See attached >> patch file). >> >> Tapan >> >> -----Original Message----- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Wednesday, October 05, 2016 3:18 PM >> To: Andrew Fish <af...@apple.com>; Daniil Egranov >> <daniil.egra...@arm.com> >> Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel-01 <edk2- >> de...@ml01.01.org>; Leif Lindholm <leif.lindh...@arm.com>; Shah, Tapan >> <tapands...@hpe.com> >> Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 >> source on the Reference Platform >> >> On 10/05/16 21:48, Andrew Fish wrote: >>> >>>> On Oct 5, 2016, at 12:24 PM, Daniil Egranov >>>> <daniil.egra...@arm.com> >> wrote: >>>> >>>> I have the same ASSERT issue on Juno platform even the >>>> EnglishDxe.inf is >> included to the platform build. If UefiShellLib has such dependency on >> the protocol then according to EDKII Module Writer's Guide you need to >> specify the dependency on protocol in the module .inf to ensure the >> drivers proper load sequence. >>>> >>>> 8.6 Dependency Expressions >>>> A dependency expression specifies the protocols that the DXE driver >>>> requires to execute. In EDK II, it is specified in the [Depex] >>>> section of INF >> file. >>>> >>> >>> The Dependency Expression is for DXE Drivers that are dispatched by >>> the >> DXE Core. A UEFI Driver from an option ROM or an Application does not >> get dispatched by the dispatch and the Depex will not help. The Depex >> ends up being a section in the FV and it has nothing to do with the >> PE/COFF image of the an application or option ROM. >>> >>> IMHO the shell should try as hard as possible to function and should >>> not >> ASSERT if some newer Protocol is missing. >> >> (Background: commit 583448b441650.) >> >> In this specific case, the protocol dependency seems possible to eliminate: >> >> - Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c >> includes the CharToUpper() function, which is minimal -- could even be >> copied or moved over -- and can translate the ASCII subset of UCS-2, >> >> - once the ASCII characters of the input string have been translated >> to upper case, the result could be searched for / compared against L"NULL" >> using BaseLib.h APIs. >> >> (Given that L"NULL" only contains characters from the ASCII subset, it >> suffices to upper-case ASCII chars in the input string. No non-ASCII >> character in the BMP can translate to ASCII N/U/L via upcasing, even >> with the real collation protocol (I trust), and no other ASCII >> characters than n/u/l will translate to N/U/L. This means that we >> won't miss an instance of NULL because we didn't upcate it (because it >> was non-ascii), and it also means we won't mistakenly match something >> non-NULL as NULL.) >> >> Just my two cents. >> >> Laszlo > > _______________________________________________ > 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 > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
