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.
Tim -----Original Message----- From: Cohen, Eugene [mailto:eug...@hp.com] Sent: Friday, September 30, 2016 9:51 AM To: Tim Lewis <tim.le...@insyde.com>; Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Kinney, Michael D <michael.d.kin...@intel.com>; Yao, Jiewen <jiewen....@intel.com>; Andrew Fish (af...@apple.com) <af...@apple.com> Subject: RE: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services Tim, My focus at the moment is on standalone SMM drivers, but in order to support 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.le...@insyde.com] > Sent: Friday, September 30, 2016 10:41 AM > To: Cohen, Eugene <eug...@hp.com>; Laszlo Ersek <ler...@redhat.com>; > edk2-devel@lists.01.org <edk2- de...@ml01.01.org>; Kinney, Michael D > <michael.d.kin...@intel.com>; Yao, Jiewen <jiewen....@intel.com>; > Andrew Fish (af...@apple.com) <af...@apple.com> > Subject: RE: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol > and Handle Services > > Eugene -- > > Since SMM drivers today are actually DXE drivers during the > initialization phase, are you going to (a) have your library check > InSmm? or (b) only work with pure SMM stand-alone drivers? > > Thanks, > > Tim > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Cohen, Eugene > Sent: Friday, September 30, 2016 9:37 AM > To: Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org > <edk2-de...@ml01.01.org>; Kinney, Michael D > <michael.d.kin...@intel.com>; Yao, Jiewen <jiewen....@intel.com>; > Andrew Fish (af...@apple.com) <af...@apple.com> > Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol > and Handle Services > > Laszlo, > > > 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 > > databases, the locator function would have to return which database > > the GUID was found. > > > > My point is that every wrapper function that returns a protocol > > interface (or several protocol interfaces), or handles, each such > > return value will likely have to be qualified with the database > > where > it was found. > > The intent here is to only search the UEFI DB from a DXE/UEFI driver > and the SMM DB from an SMM driver and not to cross between. So which > protocol DB is searched is purely a function of the module type (i.e. > what instance of the ProtocolLib it was linked against). This is > analogous to what is done with MemoryAllocationLib which either > allocates from the UEFI memory pools for UEFI/DXE modules > (UefiMemoryAllocationLib instance) or from the SMM memory pools for > SMM modules (SmmMemoryAllocationLib). > > Sorry I wasn't more clear initially. > > 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
