On 05/19/16 01:27, Andrew Fish wrote: > >> On May 18, 2016, at 2:57 PM, Laszlo Ersek <ler...@redhat.com> wrote: >> >> And, the availability of all of the arch protocols implies (as far as I >> remember -- sorry I won't do a detailed tally now) that all gRT->XXXX >> fields have been filled in with valid function pointers (by the DXE >> drivers that produce the architectural protocols). >> >> (Explaining it more on the UEFI spec level: the runtime services are >> guaranteed to exist for a UEFI driver or a UEFI application module.) >> >> I'm sure others will correct me if I made mistakes above. > > The architectural protocols represent the generic hardware abstractions > required to provide both Boot and Runtime EFI services. The reality is most > of the gRT services abstract hardware directly so they are patched. The gBS > services are more abstract, for example you can register for a timer event > prior to the gEfiTimerArchProtocolGuid AP (Architectural Protocol) getting > installed, but it will not start firing until the Timer AP is present. > > There is a good summary of APs in this global variable in the DXE Core: > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeProtocolNotify.c#L27 > > EFI_CORE_PROTOCOL_NOTIFY_ENTRY mArchProtocols[] = { > { &gEfiSecurityArchProtocolGuid, (VOID **)&gSecurity, NULL, > NULL, FALSE }, > { &gEfiCpuArchProtocolGuid, (VOID **)&gCpu, NULL, > NULL, FALSE }, > { &gEfiMetronomeArchProtocolGuid, (VOID **)&gMetronome, NULL, > NULL, FALSE }, > { &gEfiTimerArchProtocolGuid, (VOID **)&gTimer, NULL, > NULL, FALSE }, > { &gEfiBdsArchProtocolGuid, (VOID **)&gBds, NULL, > NULL, FALSE }, > { &gEfiWatchdogTimerArchProtocolGuid, (VOID **)&gWatchdogTimer, NULL, > NULL, FALSE }, > { &gEfiRuntimeArchProtocolGuid, (VOID **)&gRuntime, NULL, > NULL, FALSE }, > { &gEfiVariableArchProtocolGuid, (VOID **)NULL, NULL, > NULL, FALSE }, > { &gEfiVariableWriteArchProtocolGuid, (VOID **)NULL, NULL, > NULL, FALSE }, > { &gEfiCapsuleArchProtocolGuid, (VOID **)NULL, NULL, > NULL, FALSE }, > { &gEfiMonotonicCounterArchProtocolGuid, (VOID **)NULL, NULL, > NULL, FALSE }, > { &gEfiResetArchProtocolGuid, (VOID **)NULL, NULL, > NULL, FALSE }, > { &gEfiRealTimeClockArchProtocolGuid, (VOID **)NULL, NULL, > NULL, FALSE }, > { NULL, (VOID **)NULL, NULL, > NULL, FALSE } > }; > > The DXE Core provide functions for all gBS and gRT services. For things that > get patched later they have a CoreEfiNotAvailableYetArg1 like function so it > always safe to call, you may get EFI_NOT_AVAILABLE_YET if you call to early. > After ExitBootServices() is called some Boot Services things get NULLed out, > but at that point it is not legal to use those services. > > The simple answer is it is always safe to call a service as long as you > follow the ExitBootServices() rules, and that only applies for Runtime > drivers. > > If you look at the INF files and the Depex (Dependency Expressions) you will > notice it is common that a UEFI Driver will not have a Depex. Not having a > Depex means all the above architectural protocols are available and all of > the EFI services will just work. Some times people think no Depex is like a > Depex of TRUE. The reality is the Depex exist to solve all the chicken and > egg initializations problems in getting CPU/Chipset initialized and starting > up all the hardware required for EFI to function (Architectural Protocols).
Thanks Andrew! Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
