Re: [edk2] Understanding the OpenProtocol()/CloseProtocol()/DisconnectController() for Open by Handle.
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 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: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
Re: [edk2] Understanding the OpenProtocol()/CloseProtocol()/DisconnectController() for Open by Handle.
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
[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
