From vlrzprgts at gmail.com Mon May 23 07:47:28 2016 From: vlrzprgts at gmail.com (valerij zaporogeci) Date: Mon, 23 May 2016 14:47:28 +0300 Subject: [Fw_Os_Forum] OpenProtocol semantics Message-ID: Hi again. I see there is not much activity, but maybe it still has some sense to ask my farther questions. The specification says (in the description of UninstallProtocolInterface() service), that in order to "safely" uninstall a protocol interface, first the driver consuming it should be disconnected (through DisconnectController->Stop->CloseProtocol), and then those with BY_HANDLE_PROTOCOL, TEST_PROTOCOL and GET_PROTOCOL attributes _should be closed_. My question is HOW exactly those three types of agents are really supposed to have been "closed"? And also - is there really a necessity to hold information about those three types of agents in the data base? How is it used? By whom? Clients opening the protool one of those three ways are even not required to CloseProtocol() and there is a clear notice that for example driver opening with GET_PROTOCOL would not be notified about the protocol uninstallation\reinstallation. So there is no mechanism to safely use GET_PROTOCOL, and client opening with TEST_PROTOCOL should only rely on the status code returned. All these things make question the necessity to hold information about such types of opening in the data base. And again - how they should be closed? For example those opening with BY_HANDLE_PROTOCOL would pass the UEFI image handle as an AgentHandle. What here may be "closed"? If it's not about unloading the image (whose handle is an AgnetHandle), and this is only about the database "book keeping", then for what it is? In the case of those thee types of opening? As a consequense - would it be compliant to only keep in the data base the information about BY_DRIVER, BY_DRIVER_EXCLUSIVE, EXCLUSIVE and BY_CHILD_CONTROLLER types of opening? Thanks. From Aaron.Pop at congatec.com Mon May 23 13:29:01 2016 From: Aaron.Pop at congatec.com (Aaron.Pop at congatec.com) Date: Mon, 23 May 2016 10:29:01 -0700 Subject: [Fw_Os_Forum] OpenProtocol semantics In-Reply-To: References: Message-ID: Hi Valerij, I think you would be better off asking this question in the EDK2 mailing list. These questions that you are asking are more related to the UEFI specification than they are to operating systems that support UEFI. https://github.com/tianocore/tianocore.github.io/wiki/Getting%20Started%20with%20EDK%20II z See the "Futher Help" section with information about the edk2-devel mailing list. From: valerij zaporogeci To: fw_os_forum at mailman.uefi.org Date: 05/23/2016 04:47 AM Subject: [Fw_Os_Forum] OpenProtocol semantics Sent by: fw_os_forum-bounces at mailman.uefi.org Hi again. I see there is not much activity, but maybe it still has some sense to ask my farther questions. The specification says (in the description of UninstallProtocolInterface() service), that in order to "safely" uninstall a protocol interface, first the driver consuming it should be disconnected (through DisconnectController->Stop->CloseProtocol), and then those with BY_HANDLE_PROTOCOL, TEST_PROTOCOL and GET_PROTOCOL attributes _should be closed_. My question is HOW exactly those three types of agents are really supposed to have been "closed"? And also - is there really a necessity to hold information about those three types of agents in the data base? How is it used? By whom? Clients opening the protool one of those three ways are even not required to CloseProtocol() and there is a clear notice that for example driver opening with GET_PROTOCOL would not be notified about the protocol uninstallation\reinstallation. So there is no mechanism to safely use GET_PROTOCOL, and client opening with TEST_PROTOCOL should only rely on the status code returned. All these things make question the necessity to hold information about such types of opening in the data base. And again - how they should be closed? For example those opening with BY_HANDLE_PROTOCOL would pass the UEFI image handle as an AgentHandle. What here may be "closed"? If it's not about unloading the image (whose handle is an AgnetHandle), and this is only about the database "book keeping", then for what it is? In the case of those thee types of opening? As a consequense - would it be compliant to only keep in the data base the information about BY_DRIVER, BY_DRIVER_EXCLUSIVE, EXCLUSIVE and BY_CHILD_CONTROLLER types of opening? Thanks. _______________________________________________ Fw_os_forum mailing list Fw_os_forum at mailman.uefi.org http://lists.mailman.uefi.org/mailman/listinfo/fw_os_forum -------------- next part -------------- An HTML attachment was scrubbed... URL: From Aaron.Pop at congatec.com Mon May 23 13:25:49 2016 From: Aaron.Pop at congatec.com (Aaron.Pop at congatec.com) Date: Mon, 23 May 2016 10:25:49 -0700 Subject: [Fw_Os_Forum] Handle Data Base Statistics In-Reply-To: References: Message-ID: Hi Valerij, I can only answer based on the systems that I have experienced, but I would encourage you to write whatever application you are creating to handle any number of possible handles and to not create an upper limit or a lower limit because of the variety of UEFI implementations. >>How many handles are installed on a typical system? anywhere between 1 and a million >>What the greatest (smallest) number of handles has been encountered on UEFI systems? the max I have seen is 500+ >>How many protocols are installed on a typical system? implementation specific, each system, and its feature set cause a wide variation in the number of different protocols. >>What the greatest (smallest) number of protocols has been encountered on UEFI systems? no upper limit. The more devices in the system, the more devices attached to the system (SATA drives, USB drives, PCI cards, etc) will cause an increase in the number of handles and the number of protocols. >>How many, in average, protocols is installed on a handle? >>What the greatest number of protocols per handle has been encountered on a typical system? too many possibilities, and too many variations in implementation to give you a baseline. >>How many agents, in average, is consuming a particular protocol interface on a handle? What the greatest number of agents per protocol per handle encountered? There are too many variations to really give you answer here. Generally it depends on the drivers that are implemented in the system. >>I am asking this not of the empty interest of course, those numbers would be very useful for me in ensuring I am chosing right data organization of my UEFI implemetation, which I'm working on. :^) To give you a general answer, I would say somewhere between 50 handles to 1000 handles in a system, depending on segment (embedded systems having less handles, and server systems having more) From: valerij zaporogeci To: fw_os_forum at mailman.uefi.org Date: 05/15/2016 12:59 PM Subject: [Fw_Os_Forum] Handle Data Base Statistics Sent by: fw_os_forum-bounces at mailman.uefi.org Hi, all I have few question. Those who might know this, wouldn't you be so nice to share your knowledge? :^) The questions: How many handles are installed on a typical system? What the greatest (smallest) number of handles has been encountered on UEFI systems? How many protocols are installed on a typical system? What the greatest (smallest) number of protocols has been encountered on UEFI systems? How many, in average, protocols is installed on a handle? What the greatest number of protocols per handle has been encountered on a typical system? How many agents, in average, is consuming a particular protocol interface on a handle? What the greatest number of agents per protocol per handle encountered? I am asking this not of the empty interest of course, those numbers would be very useful for me in ensuring I am chosing right data organization of my UEFI implemetation, which I'm working on. :^) Thank you. _______________________________________________ Fw_os_forum mailing list Fw_os_forum at mailman.uefi.org http://lists.mailman.uefi.org/mailman/listinfo/fw_os_forum -------------- next part -------------- An HTML attachment was scrubbed... URL: