From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B874F1A1E3D for ; Mon, 10 Oct 2016 08:54:41 -0700 (PDT) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP; 10 Oct 2016 08:54:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,325,1473145200"; d="scan'208";a="18131444" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga005.jf.intel.com with ESMTP; 10 Oct 2016 08:54:41 -0700 Received: from orsmsx162.amr.corp.intel.com (10.22.240.85) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 10 Oct 2016 08:54:41 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.161]) by ORSMSX162.amr.corp.intel.com ([10.22.240.85]) with mapi id 14.03.0248.002; Mon, 10 Oct 2016 08:54:40 -0700 From: "Kinney, Michael D" To: "Cohen, Eugene" , "Gao, Liming" , Laszlo Ersek , "edk2-devel@lists.01.org" , "Yao, Jiewen" , "Andrew Fish (afish@apple.com)" , "Kinney, Michael D" Thread-Topic: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services Thread-Index: AdIbIt8zDF4zYVg0Qm6BbTDEpt2HcgAPkDOAAASYTYAAAl4ugAAJFCIAAZowooAATr0ZgAAN5a1Q Date: Mon, 10 Oct 2016 15:54:39 +0000 Message-ID: References: <9877647c-b348-2a36-9ac0-b520a82260d1@redhat.com> <654a587b-8f79-51ef-8ba9-a29779de46c9@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14B4820B6@shsmsx102.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2M0YTk2YzgtMjlmYi00NGJjLWE4NjQtMmJhMTkzMzZjNGMyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InRORDZxM1BzYks4czFvXC9KN0pYaTF2MUpaaVdxa21pRTY4SmNIWnI5eVBZPSJ9 x-originating-ip: [10.22.254.140] MIME-Version: 1.0 Subject: Re: RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services 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: Mon, 10 Oct 2016 15:54:41 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eugene, I am confused by one aspect of this proposal. The GUID values for PPIs, DXE Protocols, UEFI Protocols,=20 and SMM Protocols are unique. Which means if code is written to work in one phase, you can not share code to another=20 phase because the GUID values must be changed. The other libs you mentioned have the attribute that the=20 parameters to the library APIs do not have to be updated as=20 source code is moved or shared between phase types. Given that the source can not be shared, what is gained by adding a library? Would you recommend using this lib in all module types? Maybe you can share both the proposed library class APIs and typical usage from different module types. Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Co= hen, Eugene > Sent: Monday, October 10, 2016 8:24 AM > To: Gao, Liming ; Laszlo Ersek ;= edk2- > devel@lists.01.org ; Kinney, Michael D > ; Yao, Jiewen ; Andrew = Fish > (afish@apple.com) > Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and H= andle > Services >=20 > Liming, > > Could this library cover PEI PPI? >=20 > Yes - excellent suggestion for PEI - I hadn't considered it because the u= se case > hadn't come up for me yet. >=20 > > And, I think this library class will include Install, Notify and Locate= APIs. > Right? >=20 > Yes, this library class proposal incorporates all of the protocol and han= dle database > related functionality. Notify may be tricky since in DXE we have TPL and= both PEI > and SMM we have direct function callbacks but perhaps there's a way to ab= stract if we > assume a default TPL or an alternate library API to initialize the callba= ck TPL in > advance. (On the other hand this could introduce subtle bugs if driver d= evelopers > lose sight of the TPL used for callbacks on this interface.) >=20 > Given the positive feedback the next step is to publish a proposed librar= y header > file for review. >=20 > Thanks, >=20 > Eugene >=20 > From: Gao, Liming [mailto:liming.gao@intel.com] > Sent: Saturday, October 08, 2016 7:50 PM > To: Cohen, Eugene ; Laszlo Ersek ; edk2= - > devel@lists.01.org ; Kinney, Michael D > ; Yao, Jiewen ; Andrew = Fish > (afish@apple.com) > Subject: RE: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and H= andle > Services >=20 > Eugene: > Could this library cover PEI PPI? LocatePpi and LocateProtocol both ret= urn VOID**. > And, I think this library class will include Install, Notify and Locate A= PIs. Right? >=20 > typedef > EFI_STATUS > (EFIAPI *EFI_PEI_LOCATE_PPI)( > IN CONST EFI_PEI_SERVICES **PeiServices, > IN CONST EFI_GUID *Guid, > IN UINTN Instance, > IN OUT EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor OPTIONAL, > IN OUT VOID **Ppi > ); >=20 > typedef > EFI_STATUS > (EFIAPI *EFI_LOCATE_PROTOCOL)( > IN EFI_GUID *Protocol, > IN VOID *Registration, OPTIONAL > OUT VOID **Interface > ); >=20 > Thanks > Liming > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Co= hen, Eugene > Sent: Saturday, October 1, 2016 6:05 AM > To: Laszlo Ersek >; edk2- > devel@lists.01.org devel@ml01.01.org>; Kinney, Michael D > >; Yao, Jie= wen > >; Andrew Fish > (afish@apple.com) > > Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and H= andle > Services >=20 > > I believe I understood this. However, in the entry point function of an > > SMM driver, it is permitted to look for, and invoke member functions > > of, > > both SMM and DXE protocols [1]. If the library instance that is > > supposed > > to be linked into SMM drivers is tied to the SMM protocol database > > solely, then it won't be able to serve the use case when an SMM driver > > looks for a DXE protocol in its entry point function. >=20 > Agreed - non-standalone SMM drivers (notice the new terminology I'm injec= ting to > prepare us for PI 1.5) can peek over at UEFI/DXE. This is not the use cas= e I'm trying > to enable here (and I would argue as an industry is a practice we will tr= y to > discourage over time). >=20 > > ... Actually, I believe this applies even to MemoryAllocationLib. In an > > SMM driver, the SMM-tailored MemoryAllocationLib instance only > > allocates > > SMRAM, which is mostly fine. However, it is unsuitable for allocating > > (for example) EfiBootServicesData type memory, even though that too > > is > > permitted in the SMM driver's entry point function, I think. For that, > > gBS->AllocatePool() or gBS->AllocatePages() have to be called > > explicitly. >=20 > Right - so the common library abstraction allocates from the "native" mem= ory pool for > the driver type and if you want something else you have to go above and b= eyond. So in > the spirit of that precedent I'd propose the same approach for a Protocol= Lib > implementation. >=20 > Thanks, great feedback. >=20 > Eugene > _______________________________________________ > 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