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 1ACD71A1E3E for ; Mon, 10 Oct 2016 10:50:03 -0700 (PDT) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP; 10 Oct 2016 10:50:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,325,1473145200"; d="scan'208";a="18103989" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by fmsmga006.fm.intel.com with ESMTP; 10 Oct 2016 10:50:02 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.161]) by ORSMSX108.amr.corp.intel.com ([169.254.2.106]) with mapi id 14.03.0248.002; Mon, 10 Oct 2016 10:50:02 -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//+ha4CAAF3c4A== Date: Mon, 10 Oct 2016 17:50:01 +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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDhjMjM3ZmMtZTE0MC00ZTVmLWJiZjQtZmJmYzZhNzY4YmRhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlBqZzVcL0hTbWUyZnhrZk1TN1NwNEVSR1kwdDl5R2Fvd1phU3RoZ3pNUjZZPSJ9 x-originating-ip: [10.22.254.138] 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 17:50:03 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eugene, Can you provide examples in EDK II today where the same GUID Value and Stru= cture definition are used in both the UEFI Handle Database and the SMM Handle Database. I am aware of cases where an SMM Driver looks for protocols in the DXE Hand= le database, but I don't think your proposed lib would cover that case.=20 Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Co= hen, Eugene > Sent: Monday, October 10, 2016 9:23 AM > To: Kinney, Michael D ; Gao, Liming > ; Laszlo Ersek ; edk2-devel@list= s.01.org > ; Yao, Jiewen ; Andrew Fish > (afish@apple.com) > Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and H= andle > Services >=20 > Mike, >=20 > > The GUID values for PPIs, DXE Protocols, UEFI Protocols, > > and SMM Protocols are unique. Which means if code is written > > to work in one phase, you can not share code to another > > phase because the GUID values must be changed. >=20 > My original use case was a protocol definition where both the protocol st= ructure and > GUID value are shared across DXE and SMM. I was not aware of the "GUIDs = must be > unique" requirement - can you elaborate on this? >=20 > > The other libs you mentioned have the attribute that the > > parameters to the library APIs do not have to be updated as > > source code is moved or shared between phase types. >=20 > This API usage would have to be consistent across phases as well for this= proposal to > be of value. I agree - if the users of the library have to change the wa= y they call > then the library is of little (or maybe even negative) value. >=20 > > Given that the source can not be shared, what is gained by > > adding a library? >=20 > The use case is definitely to share the source. >=20 > In our envisioned use case we would have these two stacks: >=20 > DXE Driver > Library X that uses a "protocol" > ProtocolLib (DXE instance) >=20 > and >=20 > SMM Driver > Library X that uses a "protocol" > ProtocolLib (SMM instance) >=20 > so the value is being able to reuse Library X since all it depends on is = a common > protocol. The protocol would need to have absolutely identical usage (an= d in our use > case this is true). >=20 > > Would you recommend using this lib in all module types? >=20 > I was originally envisioning only DXE and SMM Drivers (and Cores) only. = Jiewen > suggested PEI which I had not considered which could theoretically be sup= ported so > long as a common "protocol" definition was usable across PEI and DXE/SMM = which is a > situation I have not yet had a need to explore. (I think the semantics o= f the PEI > no-writeable-globals due to Flash XIP drives differences in design that m= ay make this > impractical but I'm not sure.) >=20 > > Maybe you can share both the proposed library class APIs and > > typical usage from different module types. >=20 > Yes, I think I need to make it a little more real at this point. Action = Item Taken. >=20 > Eugene > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel