Re: Potentially missing CloseProtocol() call

Satoshi Tanda

Hi Laszlo,

I was almost exclusively checking edk2 headers but should have checked with
the specs. Thank you for clarifying it for me.


On Mon, Feb 8, 2021 at 7:28 AM Michael Brown <> wrote:

On 08/02/2021 14:22, Laszlo Ersek wrote:
gBS->OpenProtocol() calls that pass the EFI_OPEN_PROTOCOL_GET_PROTOCOL
argument for the "Attributes" parameter *need not* be mirrored with
gBS->CloseProtocol() calls.

Please refer to the UEFI spec on the OpenProtocol() boot service,

[...] The caller is also not required to close the protocol
interface with EFI_BOOT_SERVICES.CloseProtocol().

So you *can* call CloseProtocol(), but you don't have to.
This reminds me of a very longstanding question I've had around
OpenProtocol(): is there any defined way for something that is an
ordinary consumer (rather than a driver or child controller) to obtain a
long-lived pointer to a protocol interface?

For example:
ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/MainTextEditor.c seems
to open EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL using just HandleProtocol()
and then continues to use the pointer for the lifetime of the
application. But, as far as I can tell, there's nothing that guarantees
that this pointer remains valid?


Join to automatically receive all group messages.