From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 DDC201A1E31 for ; Wed, 5 Oct 2016 13:58:27 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 648BC8F895; Wed, 5 Oct 2016 20:58:27 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-104.phx2.redhat.com [10.3.116.104]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u95KwOtL014037; Wed, 5 Oct 2016 16:58:24 -0400 To: Tim Lewis , "Carsey, Jaben" , "Shah, Tapan" , Andrew Fish , Daniil Egranov References: <93F01BC9-4B02-467E-B900-65C6775BB0F3@apple.com> <618fd786-24d4-653c-d6b8-cb774654c644@redhat.com> <7236196A5DF6C040855A6D96F556A53F3F3F6D@msmail.insydesw.com.tw> Cc: edk2-devel-01 , Leif Lindholm From: Laszlo Ersek Message-ID: Date: Wed, 5 Oct 2016 22:58:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <7236196A5DF6C040855A6D96F556A53F3F3F6D@msmail.insydesw.com.tw> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 05 Oct 2016 20:58:27 +0000 (UTC) Subject: Re: Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 20:58:28 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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-bounces@lists.01.org] On Behalf Of Carsey, Jaben > Sent: Wednesday, October 05, 2016 1:35 PM > To: Shah, Tapan ; Laszlo Ersek ; Andrew Fish ; Daniil Egranov > Cc: Carsey, Jaben ; edk2-devel-01 ; Leif Lindholm > 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:tapandshah@hpe.com] >> Sent: Wednesday, October 05, 2016 1:25 PM >> To: Laszlo Ersek ; Andrew Fish ; >> Daniil Egranov >> Cc: Carsey, Jaben ; edk2-devel-01 > devel@ml01.01.org>; Leif Lindholm >> 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:lersek@redhat.com] >> Sent: Wednesday, October 05, 2016 3:18 PM >> To: Andrew Fish ; Daniil Egranov >> >> Cc: Carsey, Jaben ; edk2-devel-01 > devel@ml01.01.org>; Leif Lindholm ; Shah, Tapan >> >> 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 >>>> >> 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 >