Ok, so I think I get it, it's just confusing to me as to why not when
moving to the OpenProtocol (even with BY_HANDLE_PROTOCOL which could have
been BY_APP_PROTOCOL) / CloseProtocol method, have it participate in the
DisconnectController() logic and to reject if the protocol is still open.
HandleProtocol would still exist for the old stuff. So anyway, need
BY_DRIVER. Now that introduces a potential problem if you have code that
can have a protocol open in one spot and a routine that needs the protocol
in another (same application) where it opens it by itself because the
spec's say for BY_DRIVER .... *"Once a protocol interface is opened by a
driver with this attribute, no other drivers will be allowed to open the
same protocol interface with the BY_DRIVER attribute." *Unless that is
really is "no *OTHER* drivers or apps" and the same app can open and close
using BY_DRIVER all it wants - guess I'll have to play with it.*
*
On Tue, Sep 3, 2013 at 5:38 PM, Tim Lewis <[email protected]> wrote:
> 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:[email protected]]
> *Sent:* Tuesday, September 03, 2013 5:25 PM
> *To:* [email protected]
> *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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
