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

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

Eugene,

I am confused by one aspect of this proposal.

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.

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.

Given that the source can not be shared, what is gained by
adding a library?

Would you recommend using this lib in all module types?

Maybe you can share both the proposed library class APIs and
typical usage from different module types.

Mike


> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
> Sent: Monday, October 10, 2016 8:24 AM
> To: Gao, Liming <liming.gao@intel.com>; 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
> 
> Liming,
> >  Could this library cover PEI PPI?
> 
> Yes - excellent suggestion for PEI - I hadn't considered it because the use case
> hadn't come up for me yet.
> 
> > And, I think this library class will include Install, Notify and Locate APIs.
> Right?
> 
> Yes, this library class proposal incorporates all of the protocol and handle database
> related functionality.  Notify may be tricky since in DXE we have TPL and both PEI
> and SMM we have direct function callbacks but perhaps there's a way to abstract if we
> assume a default TPL or an alternate library API to initialize the callback TPL in
> advance.  (On the other hand this could introduce subtle bugs if driver developers
> lose sight of the TPL used for callbacks on this interface.)
> 
> Given the positive feedback the next step is to publish a proposed library header
> file for review.
> 
> Thanks,
> 
> Eugene
> 
> From: Gao, Liming [mailto:liming.gao@intel.com]
> Sent: Saturday, October 08, 2016 7:50 PM
> To: Cohen, Eugene <eugene@hp.com>; 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
> 
> Eugene:
>  Could this library cover PEI PPI?  LocatePpi and LocateProtocol both return VOID**.
> And, I think this library class will include Install, Notify and Locate APIs. Right?
> 
> typedef
> EFI_STATUS
> (EFIAPI *EFI_PEI_LOCATE_PPI)(
>   IN CONST EFI_PEI_SERVICES            **PeiServices,
>   IN CONST EFI_GUID                    *Guid,
>   IN UINTN                             Instance,
>   IN OUT   EFI_PEI_PPI_DESCRIPTOR      **PpiDescriptor OPTIONAL,
>   IN OUT   VOID                        **Ppi
>   );
> 
> typedef
> EFI_STATUS
> (EFIAPI *EFI_LOCATE_PROTOCOL)(
>   IN  EFI_GUID  *Protocol,
>   IN  VOID      *Registration, OPTIONAL
>   OUT VOID      **Interface
>   );
> 
> Thanks
> Liming
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohen, Eugene
> Sent: Saturday, October 1, 2016 6:05 AM
> To: Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>>; edk2-
> devel@lists.01.org<mailto:edk2-devel@lists.01.org> <edk2-
> devel@ml01.01.org<mailto:edk2-devel@ml01.01.org>>; Kinney, Michael D
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Yao, Jiewen
> <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Andrew Fish
> (afish@apple.com<mailto:afish@apple.com>) <afish@apple.com<mailto:afish@apple.com>>
> Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle
> Services
> 
> > I believe I understood this. However, in the entry point function of an
> > SMM driver, it is permitted to look for, and invoke member functions
> > of,
> > both SMM and DXE protocols [1]. If the library instance that is
> > supposed
> > to be linked into SMM drivers is tied to the SMM protocol database
> > solely, then it won't be able to serve the use case when an SMM driver
> > looks for a DXE protocol in its entry point function.
> 
> Agreed - non-standalone SMM drivers (notice the new terminology I'm injecting to
> prepare us for PI 1.5) can peek over at UEFI/DXE. This is not the use case I'm trying
> to enable here (and I would argue as an industry is a practice we will try to
> discourage over time).
> 
> > ... Actually, I believe this applies even to MemoryAllocationLib. In an
> > SMM driver, the SMM-tailored MemoryAllocationLib instance only
> > allocates
> > SMRAM, which is mostly fine. However, it is unsuitable for allocating
> > (for example) EfiBootServicesData type memory, even though that too
> > is
> > permitted in the SMM driver's entry point function, I think. For that,
> > gBS->AllocatePool() or gBS->AllocatePages() have to be called
> > explicitly.
> 
> Right - so the common library abstraction allocates from the "native" memory pool for
> the driver type and if you want something else you have to go above and beyond. So in
> the spirit of that precedent I'd propose the same approach for a ProtocolLib
> implementation.
> 
> Thanks, great feedback.
> 
> Eugene
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel