From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.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 983F51A1E31 for ; Wed, 5 Oct 2016 13:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1475701167; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=x/+v2uVuwcyQr8SiWlwRcNkzQ7WlB4rNc639DR2W5uk=; b=Zkfvp3nsPH3UrMo+eif4G9zViKu+Y2gv1Dyfq4A2vzRbVUVXmmcLbZ1xJ1sBTi87 UglgFFVVZAJN7ee17nwEYfrXbD/5hCb7qvVRp+s9ko6BgY9opv4cSxWZJFhshVXB VUi0yYBaw/Dc1TGBvw6RUuVTeA+bvQ2YSp4nq5pL2IxRkHZcXIZr73Prm0a/Az/Q DYOaziKeErP/Cr/bp2nf65CGyFCSqJFa1SoTThhoFIiUDxTc2EUkKhKb0LPf72KL 8rlPMu1PKqJxWSVg6hJmyT3OyK/VaqOkLlu15uJLt4SsC9yJ9+5aMSOCuctpO7r+ 5N+n84tzjMgqbhtsOuLV/g==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 5A.9A.06862.FA965F75; Wed, 5 Oct 2016 13:59:27 -0700 (PDT) X-AuditID: 11973e15-359fb70000001ace-c6-57f569af4527 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay6.apple.com (Apple SCV relay) with SMTP id 63.CA.23613.EA965F75; Wed, 5 Oct 2016 13:59:27 -0700 (PDT) MIME-version: 1.0 Received: from [17.153.37.250] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OEL00FA3E9L2600@nwk-mmpp-sz13.apple.com>; Wed, 05 Oct 2016 13:59:26 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: Date: Wed, 05 Oct 2016 13:59:26 -0700 Cc: Tim Lewis , "Carsey, Jaben" , "Shah, Tapan" , Daniil Egranov , edk2-devel-01 , Leif Lindholm Message-id: References: <93F01BC9-4B02-467E-B900-65C6775BB0F3@apple.com> <618fd786-24d4-653c-d6b8-cb774654c644@redhat.com> <7236196A5DF6C040855A6D96F556A53F3F3F6D@msmail.insydesw.com.tw> To: Laszlo Ersek X-Mailer: Apple Mail (2.3226) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUi2FAYpbs+82u4wfRdohZbWm+xW6zb843d YmPTH1aLRf1f2SyWHdvBYjFx4w9mi4s/VjE5sHusmbeG0WPXrkZ2j/Y3/9k8Fu95yeQx6cJj Zo/3+66yBbBFcdmkpOZklqUW6dslcGVM3r6IreCeTsWL7dENjDtUuhg5OSQETCR+LPnNDGIL CexllJj3Xg0mvvneUZYuRi6g+CFGiQ2r94AV8QoISvyYfA8owcHBLCAvcfC8LEiYWUBL4vuj Vqj6d4wSO7bcZgVJCAuIS7w7s4kZwk6ReDa1iRHEZhNQllgx/wM7yBxOATuJ5VfZQcIsAqoS 985NAJvDDDKne84Hdoi9NhK/L05khFiwilVi9vM1YINEBFQkZk94wAQySEJAVmL2Ly+QGgmB 72wS6z/PYJ/AKDwLyd2zEO6eheTuBYzMqxiFchMzc3Qz88z0EgsKclL1kvNzNzGCIma6negO xjOrrA4xCnAwKvHwGmh8DRdiTSwrrsw9xCjNwaIkzsv94XO4kEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBkbOW6utP/5Lue9TNmcr38s7x6s6JaKYGlp7tNy2SV1evSRs4tSav+ec7/LULhYr ST21qLnI/UPm2XCjD9qxUjc6OxXC0lZeua+xr/tpAm9GwVd5p46X0+z7FlzaFL1ImZvDx92h bd9V7dup8gFzz4Uvt71k11Z0NnsW32qF/fffrj6rrmkZdkSJpTgj0VCLuag4EQBHleAeeQIA AA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUi2FB8Q3d95tdwg92zWC22tN5it1i35xu7 xcamP6wWi/q/slksO7aDxWLixh/MFhd/rGJyYPdYM28No8euXY3sHu1v/rN5LN7zkslj0oXH zB7v911lC2CL4rJJSc3JLEst0rdL4MqYvH0RW8E9nYoX26MbGHeodDFyckgImEhsvneUBcIW k7hwbz1bFyMXh5DAIUaJDav3MIMkeAUEJX5MvgdUxMHBLCAvcfC8LEiYWUBL4vujVhaI+neM Eju23GYFSQgLiEu8O7OJGcJOkXg2tYkRxGYTUJZYMf8DO8gcTgE7ieVX2UHCLAKqEvfOTQCb wwwyp3vOB3aIvTYSvy9OZIRYsIpVYvbzNWCDRARUJGZPeMAEMkhCQFZi9i+vCYyCs5CcOgvh 1FlITl3AyLyKUaAoNSex0kwvsaAgJ1UvOT93EyM49AujdjA2LLc6xCjAwajEw3tD9Wu4EGti WXFlLjAsOJiVRHi50oBCvCmJlVWpRfnxRaU5qcWHGJOBHpjILCWanA+My7ySeEMTEwMTY2Mz Y2NzE3PShJXEeXdf/hQuJJCeWJKanZpakFoEs4WJg1OqgTG3tET7162UzQzsmieUQrY1vMvu /dzI778v4ue1jV2zRBVyvaYejzh4/V17X8nSOYzs9+/blcnnXDLx++z65rW1tZWC432BB4s2 CS5lFXoVYPj94WPeHP7VEwIl+t+/anly4218ycaOO0cqDvrvnBcuVbnswvGIuzNPzOLruZTX 2fHKz2iuyWMlluKMREMt5qLiRAAjXnlCwQIAAA== 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:59:27 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Oct 5, 2016, at 1:58 PM, Laszlo Ersek wrote: > > 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. > Looks like he has a DXE Driver that consume the ShellLib. Thanks, Andrew Fish > 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 >> >