David -
To answer your specific questions: no EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL does
not participate in DisconnectController() and no, it cannot reject it somehow.
They are simply closed. Why? As the paragraph indicates, this was a part of EFI
1.10 (ancient history) and was worried about EFI 1.02 compatibility. In EFI
1.02 there was only HandleProtocol. None of the Open/Close stuff existed. When
the driver model was added in EFI 1.10, there was a problem of backward
compatibility: how to handle callers to HandleProtocol (i.e. agents) since they
did not register their own handles when they called HandleProtocol.
This causes a problem for CloseProtocol, since it wants to cleanly disconnect
things, but for people who called HandleProtocol(), there was no record of who
should be disconnected. In those cases, the bold text simply indicates that for
those people who didn't register themselves (either by using HandleProtocol()
or by using the HANDLE_PROTOCOL/GET_PROTOCOL/TEST_PROTOCOL versions of
OpenProtocol()), they are just closed without warning.
After this point, if the kernel (after DisconnectController() and clearing the
HANDLE/GET/TEST folks) still detects that there are outstanding folks (drivers
or apps) hanging on to handles, it will return EFI_ACCESS_DENIED
From: David F. [mailto:df7...@gmail.com]
Sent: Tuesday, September 03, 2013 5:25 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Understanding the
OpenProtocol()/CloseProtocol()/DisconnectController() for Open by Handle.
In the *** BOLD *** sentence below. What exactly are they trying to say? What
are the "agents"? Does this mean EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL also
participates in the DisconnectController() call and can reject it some how?
Or is the "agent" the application/process/whatever and it shuts it down or they
are closed down cleanly?
----
EFI 1.10 Extension
The extension to this service directly addresses the limitations described in
the section above. There may be some drivers that are currently consuming the
protocol interface that needs to be uninstalled, so it may be dangerous to just
blindly remove a protocol interface from the system. Since the usage of
protocol interfaces is now being tracked for components that use the
OpenProtocol() and CloseProtocol() boot services, a safe version of this
function can be implemented. Before the protocol interface is removed, an
attempt is made to force all the drivers that are consuming the protocol
interface to stop consuming that protocol interface. This is done by calling
the boot service DisconnectController() for the driver that currently have the
protocol interface open with an attribute of EFI_OPEN_PROTOCOL_BY_DRIVER or
EFI_OPEN_PROTOCOL_BY_DRIVER | EFI_OPEN_PROTOCOL_EXCLUSIVE.
If the disconnect succeeds, then those agents will have called the boot service
CloseProtocol() to release the protocol interface. *** Lastly, all of the
agents that have the protocol interface open with an attribute of
EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL, EFI_OPEN_PROTOCOL_GET_PROTOCOL, or
EFI_OPEN_PROTOCOL_TEST_PROTOCOL are closed. *** If there are any agents
remaining that still have the protocol interface open, the protocol interface
is not removed from the handle and EFI_ACCESS_DENIED is returned. In addition,
all of the drivers that were disconnected with the boot service
DisconnectController() earlier, are reconnected with the boot service
ConnectController(). If there are no agents remaining that are consuming the
protocol interface, then the protocol interface is removed from the handle as
described above.
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
