Re: RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services

[Tim Lewis <tim.lewis@insyde.com>]

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-bounces@lists.01.org] On Behalf Of Cohen, Eugene
Sent: Friday, September 30, 2016 9:37 AM
To: Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Kinney, Michael D <michael.d.kinney@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Andrew Fish (afish@apple.com) <afish@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