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:[email protected]] Sent: Friday, September 30, 2016 9:51 AM To: Tim Lewis <[email protected]>; Laszlo Ersek <[email protected]>; [email protected] <[email protected]>; Kinney, Michael D <[email protected]>; Yao, Jiewen <[email protected]>; Andrew Fish ([email protected]) <[email protected]> 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:[email protected]] > Sent: Friday, September 30, 2016 10:41 AM > To: Cohen, Eugene <[email protected]>; Laszlo Ersek <[email protected]>; > [email protected] <edk2- [email protected]>; Kinney, Michael D > <[email protected]>; Yao, Jiewen <[email protected]>; > Andrew Fish ([email protected]) <[email protected]> > 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:[email protected]] On Behalf Of > Cohen, Eugene > Sent: Friday, September 30, 2016 9:37 AM > To: Laszlo Ersek <[email protected]>; [email protected] > <[email protected]>; Kinney, Michael D > <[email protected]>; Yao, Jiewen <[email protected]>; > Andrew Fish ([email protected]) <[email protected]> > 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 > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
