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

["Kinney, Michael D" <michael.d.kinney@intel.com>]

Eugene,

Can you provide examples in EDK II today where the same GUID Value and Structure definition
are used in both the UEFI Handle Database and the SMM Handle Database.

I am aware of cases where an SMM Driver looks for protocols in the DXE Handle database,
but I don't think your proposed lib would cover that case. 

Mike

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
> Sent: Monday, October 10, 2016 9:23 AM
> To: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> <liming.gao@intel.com>; Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org
> <edk2-devel@ml01.01.org>; 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
> 
> Mike,
> 
> > The GUID values for PPIs, DXE Protocols, UEFI Protocols,
> > and SMM Protocols are unique.  Which means if code is written
> > to work in one phase, you can not share code to another
> > phase because the GUID values must be changed.
> 
> My original use case was a protocol definition where both the protocol structure and
> GUID value are shared across DXE and SMM.  I was not aware of the "GUIDs must be
> unique" requirement - can you elaborate on this?
> 
> > The other libs you mentioned have the attribute that the
> > parameters to the library APIs do not have to be updated as
> > source code is moved or shared between phase types.
> 
> This API usage would have to be consistent across phases as well for this proposal to
> be of value.  I agree - if the users of the library have to change the way they call
> then the library is of little (or maybe even negative) value.
> 
> > Given that the source can not be shared, what is gained by
> > adding a library?
> 
> The use case is definitely to share the source.
> 
> In our envisioned use case we would have these two stacks:
> 
> DXE Driver
> Library X that uses a "protocol"
> ProtocolLib (DXE instance)
> 
> and
> 
> SMM Driver
> Library X that uses a "protocol"
> ProtocolLib (SMM instance)
> 
> so the value is being able to reuse Library X since all it depends on is a common
> protocol.  The protocol would need to have absolutely identical usage (and in our use
> case this is true).
> 
> > Would you recommend using this lib in all module types?
> 
> I was originally envisioning only DXE and SMM Drivers (and Cores) only.  Jiewen
> suggested PEI which I had not considered which could theoretically be supported so
> long as a common "protocol" definition was usable across PEI and DXE/SMM which is a
> situation I have not yet had a need to explore.  (I think the semantics of the PEI
> no-writeable-globals due to Flash XIP drives differences in design that may make this
> impractical but I'm not sure.)
> 
> > Maybe you can share both the proposed library class APIs and
> > typical usage from different module types.
> 
> Yes, I think I need to make it a little more real at this point.  Action Item Taken.
> 
> Eugene
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel