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

2016-10-11 Thread Kinney, Michael D
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, > Eugene > Sent: Tuesday, October 11, 2016 8:18 AM > To: Kinney, Michael D ; Gao, Liming > ; > Laszlo Ersek ;

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

2016-10-11 Thread Cohen, Eugene
Mike, > I agree that accessing DXE protocols in an SMI handler is not allowed. > > It is legal for an SMM Driver to access DXE content in the SMM Driver Entry > Point. To digress from the original thread a bit.. There's legal from a PI perspective but for the situations that warrant stricter

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

2016-10-10 Thread Kinney, Michael D
Eugene, I agree that accessing DXE protocols in an SMI handler is not allowed. It is legal for an SMM Driver to access DXE content in the SMM Driver Entry Point. For example, if an SMM Driver depends on PCDs, the PCD values can be read from the PCD database through the PCD Protocol in the

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

2016-10-10 Thread Cohen, Eugene
Mike, > 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. The example exists in our internal code right now. We have two platform families: one with SMM and one without. We

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

2016-10-10 Thread Kinney, Michael D
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

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

2016-10-10 Thread Cohen, Eugene
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

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

2016-10-10 Thread Kinney, Michael D
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

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

2016-10-10 Thread Cohen, Eugene
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

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

2016-10-08 Thread Gao, Liming
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

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

2016-09-30 Thread Cohen, Eugene
> 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 >

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

2016-09-30 Thread Laszlo Ersek
On 09/30/16 18:36, Cohen, Eugene wrote: > Laszlo, > >> As far as I know: >> - the DXE and SMM protocol databases are distinct, >> - the same protocol GUID may or may not be installed (on one or more) >> handle(s) in either, >> - even if a protocol GUID exists uniquely in exactly one of those

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

2016-09-30 Thread Cohen, Eugene
Tim, Agreed - When BaseTools gets the standalone support I expect us to be able to differentiate library instances. I wanted to gather feedback now while we prototype on a branch. Eugene > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > Of

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

2016-09-30 Thread Tim Lewis
Eugene -- Since the standalone file type isn't yet in the EDK2 code, the build system will not be able to make this distinction in the library's INF file. Tim -Original Message- From: Cohen, Eugene [mailto:eug...@hp.com] Sent: Friday, September 30, 2016 9:51 AM To: Tim Lewis

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

2016-09-30 Thread Cohen, Eugene
Tim, My focus at the moment is on standalone SMM drivers, but in order to support the dual-mode DXE_SMM_DRIVER modules we could have another instance that does the InSmm check at runtime. Eugene > -Original Message- > From: Tim Lewis [mailto:tim.le...@insyde.com] > Sent: Friday,

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

2016-09-30 Thread Tim Lewis
Eugene -- Since SMM drivers today are actually DXE drivers during the initialization phase, are you going to (a) have your library check InSmm? or (b) only work with pure SMM stand-alone drivers? Thanks, Tim -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]

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

2016-09-30 Thread Cohen, Eugene
Laszlo, > As far as I know: > - the DXE and SMM protocol databases are distinct, > - the same protocol GUID may or may not be installed (on one or more) > handle(s) in either, > - even if a protocol GUID exists uniquely in exactly one of those databases, > the locator function would have to

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

2016-09-30 Thread Laszlo Ersek
On 09/30/16 16:13, Cohen, Eugene wrote: > Request for Comments... > > Both UEFI/DXE and SMM support the protocol / handle database concept. > Some protocol definitions are able used in both environments with > different implementations behind them. > > We'd like to create a library that could be

[edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services

2016-09-30 Thread Cohen, Eugene
Request for Comments... Both UEFI/DXE and SMM support the protocol / handle database concept. Some protocol definitions are able used in both environments with different implementations behind them. We'd like to create a library that could be used in either DXE or SMM making use of protocol