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

["Gao, Liming" <liming.gao@intel.com>]

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>; 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

> 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