> -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 ;
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
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
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
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
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
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
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
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
> 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
>
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
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
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
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,
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]
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
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
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
18 matches
Mail list logo