From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from msmail.insydesw.com.tw (ms.insydesw.com [211.75.113.220]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3A43F1A1E0F for ; Fri, 30 Sep 2016 09:55:48 -0700 (PDT) Received: from msmail.insydesw.com.tw ([fe80::74f7:f173:f4aa:9a05]) by msmail.insydesw.com.tw ([fe80::74f7:f173:f4aa:9a05%11]) with mapi id 14.01.0438.000; Sat, 1 Oct 2016 00:55:46 +0800 From: Tim Lewis To: "Cohen, Eugene" , Laszlo Ersek , "edk2-devel@lists.01.org" , "Kinney, Michael D" , "Yao, Jiewen" , "Andrew Fish (afish@apple.com)" Thread-Topic: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services Thread-Index: AdIbIt8zDF4zYVg0Qm6BbTDEpt2Hcv//gQyAgAAkwoD//3j2oIAAiyGA//95pZA= Date: Fri, 30 Sep 2016 16:55:45 +0000 Message-ID: <7236196A5DF6C040855A6D96F556A53F3F2407@msmail.insydesw.com.tw> References: <9877647c-b348-2a36-9ac0-b520a82260d1@redhat.com> <7236196A5DF6C040855A6D96F556A53F3F23AA@msmail.insydesw.com.tw> In-Reply-To: Accept-Language: en-US, zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.100.107] 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: Fri, 30 Sep 2016 16:55:48 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eugene -- Since the standalone file type isn't yet in the EDK2 code, the build system= will not be able to make this distinction in the library's INF file.=20 Tim -----Original Message----- From: Cohen, Eugene [mailto:eugene@hp.com]=20 Sent: Friday, September 30, 2016 9:51 AM To: Tim Lewis ; Laszlo Ersek ; edk= 2-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 Han= dle Services Tim, My focus at the moment is on standalone SMM drivers, but in order to suppor= t the dual-mode DXE_SMM_DRIVER modules we could have another instance that = does the InSmm check at runtime. Eugene > -----Original Message----- > From: Tim Lewis [mailto:tim.lewis@insyde.com] > Sent: Friday, September 30, 2016 10:41 AM > To: Cohen, Eugene ; Laszlo Ersek ;=20 > edk2-devel@lists.01.org ; Kinney, Michael D=20 > ; Yao, Jiewen ;=20 > Andrew Fish (afish@apple.com) > Subject: RE: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol=20 > and Handle Services >=20 > Eugene -- >=20 > Since SMM drivers today are actually DXE drivers during the=20 > initialization phase, are you going to (a) have your library check=20 > InSmm? or (b) only work with pure SMM stand-alone drivers? >=20 > Thanks, >=20 > Tim >=20 > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of=20 > Cohen, Eugene > Sent: Friday, September 30, 2016 9:37 AM > To: Laszlo Ersek ; edk2-devel@lists.01.org=20 > ; Kinney, Michael D=20 > ; Yao, Jiewen ;=20 > Andrew Fish (afish@apple.com) > Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol=20 > and Handle Services >=20 > Laszlo, >=20 > > As far as I know: > > - the DXE and SMM protocol databases are distinct, > > - the same protocol GUID may or may not be installed (on one or > more) > > handle(s) in either, > > - even if a protocol GUID exists uniquely in exactly one of those=20 > > databases, the locator function would have to return which database=20 > > the GUID was found. > > > > My point is that every wrapper function that returns a protocol=20 > > interface (or several protocol interfaces), or handles, each such=20 > > return value will likely have to be qualified with the database=20 > > where > it was found. >=20 > The intent here is to only search the UEFI DB from a DXE/UEFI driver=20 > and the SMM DB from an SMM driver and not to cross between. So which=20 > protocol DB is searched is purely a function of the module type (i.e.=20 > what instance of the ProtocolLib it was linked against). This is=20 > analogous to what is done with MemoryAllocationLib which either=20 > allocates from the UEFI memory pools for UEFI/DXE modules=20 > (UefiMemoryAllocationLib instance) or from the SMM memory pools for=20 > SMM modules (SmmMemoryAllocationLib). >=20 > Sorry I wasn't more clear initially. >=20 > Eugene > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel