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

["Cohen, Eugene" <eugene@hp.com>]

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