Adding Mike, Liming & Jeff
On 03/22/16 08:10, Laszlo Ersek wrote:
> On 03/22/16 06:59, Jordan Justen wrote:
>> Why not a guid based event, similar to gIdleLoopEventGuid?
>
> Two reasons:
>
> - specifically, it keeps the current structure of the AcpiPlatformDxe
> driver (i.e., we stick to the way the PCI bus driver installs
> gEfiPciEnumerationCompleteProtocolGuid, we just use a different GUID and
> tie it to a different circumstance)
>
> - (I vaguely think I might have mentioned this earlier) generally, I
> prefer protocol installations to events, in this kind of situation. The
> protocol stays there permanently, and in general it allows the
> "consuming" driver to load & start after the protocol is installed.
>
> The generic reason doesn't apply in this case, but I preferred to stick
> with the pattern. Do you have a strong reason to dislike it?
By the way: I seem to recall your earlier idea about abstracting the
signaling of event groups into UefiLib.
Investigating the core UefiLib instance
("MdePkg/Library/UefiLib/UefiLib.c"), I find that this kind of
functionality exists already. See the utility functions
EfiNamedEventListen() and EfiNamedEventSignal() especially -- the latter
takes only an EFI_GUID, so the function signature seems just right.
However, these functions are not implemented with event groups; instead
they too are based on RegisterProtocolNotify() and
InstallProtocolInterface(). I'm unsure about the reason.
I envisage an uphill battle for coming up with a new pair of functions
- for the same UefiLib class & core instance,
- with identical signaling functionality but different implementation
(= event groups),
- with names clear enough that would prevent the client code programmer
from mixing up the two implementations (like creating the listener
with RegisterProtocolNotify() and trying to signal it with
SignalEvent()).
For our use case specifically, the listener function wouldn't even be
useful. All we'd need is: create an event in the specified event group,
with an empty callback function; signal the event; close the event.
If this functionality is welcome to UefiLib (i.e., to the class and the
two existing instances in the tree), I'm willing to implement it, and to
rebase this series on top. (It would result in several more patches
because the current signaling of EndOfDxe in the OvmfPkg and ArmVirtPkg
PlatformBdsLib instances should be rebased as well.)
However, I'll need buy-in from the UefiLib maintainers (Mike, Liming,
Jeff) *in advance*. I have no capacity to rework this series only to see
the first patches (= for MdePkg and IntelFrameworkPkg) be rejected or
drag on forever.
Again, the entire functionality that would be abstracted into UefiLib, is:
EFI_STATUS
EFIAPI
EfiEventGroupSignal (
IN CONST EFI_GUID *EventGroupGuid
)
{
EFI_STATUS Status;
EFI_EVENT Event;
Status = gBS->CreateEventEx (
EVT_NOTIFY_SIGNAL,
TPL_CALLBACK,
InternalEmptyFunction,
NULL, // NotifyContext
EventGroupGuid,
&Event);
if (EFI_ERROR (Status)) {
return Status;
}
Status = gBS->SignalEvent (Event);
gBS->CloseEvent (Event);
return Status;
}
Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
