From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.171.2.68; helo=ma1-aaemail-dr-lapp02.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 0C59421103DBE for ; Thu, 6 Sep 2018 15:31:21 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id w86MQoE2057609; Thu, 6 Sep 2018 15:31:17 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=U6Bmzn5x1brS65N/GCpGKuRyr4crqWMzBDBTB0k684A=; b=gT/PwYDCQXHtq/8qRH/oeKqQizwqJ6JQGOb6kn3C03q5uoC73nr6voVoEYYy/ZEvr+T1 nA5pNmyzRHleRWLqkv3UZpqalseA7gjopurKwWVWLYbsvCde6lJJepPh13o/APnRaJSG Em4FMtAIreFU6kUs3xCzUwMrOQMRfHBHRXzQwiSw1GDlbuOGzNrjngroNrkLAJ8pVEaD eU9//VPfmLsKlDW9y1rW/zoEgiP9Y6jsXOITmDDbKMCGQMlHcgTjTJTMTvqXfOnAHaX4 fmj2ReY1OVYc6u0TeDen3ymiD1LjBq2gx29Ihe/EhsvZIgFiTHkyCrQ0vDLkkyn+u38M UA== Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2m7qexytwg-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 06 Sep 2018 15:31:16 -0700 MIME-version: 1.0 Received: from ma1-mmpp-sz11.apple.com (ma1-mmpp-sz11.apple.com [17.171.128.33]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PEN003SPNW3EXF0@mr2-mtap-s01.rno.apple.com>; Thu, 06 Sep 2018 15:31:15 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz11.apple.com by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PEN00H00NISM800@ma1-mmpp-sz11.apple.com>; Thu, 06 Sep 2018 15:31:15 -0700 (PDT) X-Va-A: X-Va-T-CD: da3a4df698400084da27c6ab403bcb35 X-Va-E-CD: 5cce92e979dc82d2dd4d76128a280c0f X-Va-R-CD: 0972fc81b48dbbdab5e0f3435d1cb1dc X-Va-CD: 0 X-Va-ID: 91930ed3-2693-4dd2-b40a-9881c8427377 X-V-A: X-V-T-CD: da3a4df698400084da27c6ab403bcb35 X-V-E-CD: 5cce92e979dc82d2dd4d76128a280c0f X-V-R-CD: 0972fc81b48dbbdab5e0f3435d1cb1dc X-V-CD: 0 X-V-ID: 239bde75-7df6-443a-b590-180df016ef94 Received: from process_milters-daemon.ma1-mmpp-sz11.apple.com by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PEN00J00NQ5ID00@ma1-mmpp-sz11.apple.com>; Thu, 06 Sep 2018 15:31:15 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-06_11:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp23.corp.apple.com-10000_instance1 Received: from [17.234.213.77] (unknown [17.234.213.77]) by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PEN00HEANVZSD20@ma1-mmpp-sz11.apple.com>; Thu, 06 Sep 2018 15:31:15 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: Date: Thu, 06 Sep 2018 15:31:29 -0700 Cc: Laszlo Ersek , "Ni, Ruiyu" , Leif Lindholm , "edk2-devel@lists.01.org" , "Carsey, Jaben" , Alexander Graf , Heinrich Schuchardt , AKASHI Takahiro Message-id: <8D1E7796-B9F4-49B4-B0D1-43956930D10B@apple.com> References: <20180905172546.hxc2vqn6pgmr2zqs@bivouac.eciton.net> <8f700131-c4da-59bf-e1d3-0f4000e65215@redhat.com> <4C4EEEA0-8656-49D5-9DEE-8A810F6D8FC2@apple.com> <14abfd24-94eb-53f0-8ed6-721cbbc55137@Intel.com> To: Mike Kinney X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-06_11:, , signatures=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: Thu, 06 Sep 2018 22:31:22 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Mike, More possible ideas I think from a 10,000 foot level the issue is the Public definition of the HOB lib calls out the ASSERT behavior 5) Make the ASSERT() conditional via a PCD and update the HOB lib definition. For platforms that make HOBs options GetHobList() must be called 1st, and non of the other APIs can be called on platforms that don't support HOBs. That has the upside of only needing to make the Lib constructor and GetHobList() ASSERTs conditional onPCDs. 6) Split the existing UefiBootManagerLib in a backwards compatible way by making a new UefiBootLib. UefiBootManagerLib.h can include UefiBootLib.h and UefiBootManagerLib.inf could depend on UefiBootLib. This would only require adding UefiBootLib to the library class of existing DSC files. Thanks, Andrew Fish > On Sep 6, 2018, at 10:17 AM, Kinney, Michael D wrote: > > Ray, > > I have a few ideas here. > > 1) Add a new UefiHobLib instance that is only for > use by UEFI Drivers and UEFI Applications. It fails > gracefully if the HOB List is not in the UEFI System > Configuration Table. BootMode if HobList is not present > can be BOOT_WITH_FULL_CONFIGURATION. > > 2) Remove ASSERT() from the CONSTRUCTOR and a return > NULL from the Get*() functions if mHobList is NULL. > BootMode can be BOOT_WITH_FULL_CONFIGURATION if > mHobList is NULL. > > 3) Update UEFI Shell to not use the UefiBootManagerLib. > This would add duplicate code to the UEFI Shell. > > 4) Update UefiBootManagerLib to not use the HobLib. > Instead look for HobList in UEFI System Configuration > Table and fail gracefully if it is not present. > This would add some duplicate code to the > UefiBootManagerLib to parse the Hob List. > > Best regards, > > Mike > >> -----Original Message----- >> From: Laszlo Ersek [mailto:lersek@redhat.com] >> Sent: Thursday, September 6, 2018 2:57 AM >> To: Ni, Ruiyu ; Andrew Fish >> >> Cc: Leif Lindholm ; edk2- >> devel@lists.01.org; Carsey, Jaben >> ; Alexander Graf >> ; Heinrich Schuchardt >> ; AKASHI Takahiro >> ; Kinney, Michael D >> >> Subject: Re: portability of ShellPkg >> >> On 09/06/18 04:34, Ni, Ruiyu wrote: >>> On 9/6/2018 3:47 AM, Andrew Fish wrote: >>>> >>>> Laszlo, >>>> >>>> gEfiMemoryTypeInformationGuid is an edk2/MdeModulePkg >> concept used to >>>> give the DXE Core hints on how to reduce >> fragmentation in the memory >>>> map. Typically there is code in PEI that creates a >> HOB and may consume >>>> a variable written by the BDS. This library seems to >> be the generic >>>> way to do it on an edk2 platform. >>>> >>>> Thus this library is not just PI but edk2 >> MdeModulePkg specific in >>>> some of its assumptions. In general this >> UefiBootManagerLib seems >>>> focused on construction and edk2 BDS. It would >> probably make more >>>> sense to break out the UEFI Spec related bits so they >> could be used in >>>> generic UEFI Applications. >>>> >>>> Thanks, >>>> >>>> Andrew Fish >>>> >>>> >>> >>> Andrew, >>> I agree refactoring UefiBootManagerLib to separate the >> pure UEFI, pure >>> PI and EDKII specific looks much more cleaner. >>> So far the PI related bits in UefiBootManagerLib may >> include: >>> 1. Hob access for S4 support (memory type information >> HOB). >>> 2. Boot from Firmware Volume support. >>> >>> But that requires introducing two or more library >> classes so affecting >>> all existing platforms. EfiCreateEventLegacyBootEx() >> in UefiLib also >>> touches PI event gEfiEventLegacyBootGuid. >>> >>> And I think the value of refactor might be small. >>> >>> I think root cause of this problem is not >> UefiBootManagerLib includes >>> PI, it's the assertion in DxeHobLib. >>> So I am thinking maybe a very light fix is to remove >> the constructor of >>> DxeHobLib. >>> >>> I talked with Liming about this and he suggested that >> instead of >>> removing the constructor, it's safer to just remove >> the assertion in the >>> constructor. Because removing the constructor of >> HobLib may cause >>> AutoGen process generates a different order of library >> constructors >>> calling sequence, which may break the platform. >>> >>> So I propose to just remove the assertion in DxeHobLib >> constructor. >>> Thoughts? >> >> I think keeping the constructor itself is important and >> a good idea. >> >> I also think that we should *perhaps* keep the assertion >> *somewhere*, >> just not in the constructor. Because, at least some of >> the HobLib APIs >> cannot return errors (and their callers expect them to >> succeed at all >> times). This suggests we should still trip assertions >> when a HobLib API >> is called *in practice* on a non-PI UEFI platform. >> >> Thanks >> Laszlo