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:[email protected]] On Behalf Of Cohen, > Eugene > Sent: Monday, October 10, 2016 9:23 AM > To: Kinney, Michael D <[email protected]>; Gao, Liming > <[email protected]>; Laszlo Ersek <[email protected]>; > [email protected] > <[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 > > 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
