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 [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
