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
