> On May 27, 2016, at 12:14 PM, valerij zaporogeci <[email protected]> wrote: > > 2016-05-27 20:51 GMT+03:00, Andrew Fish <[email protected]>: >> >>> On May 27, 2016, at 7:23 AM, valerij zaporogeci <[email protected]> >>> wrote: >>> >>> >>> Hi, there. Sorry for my english. >> >> I'm a native English speaker but I'm a little dyslexic so I've been known to >> mangle English too. >> >>> I was asking questions on >>> Fw_Os_Forum, but was redirected here, as it turned my questions might >>> be more relevant here than there. Hope so. >>> My question is about ConnectController semantics. >>> The specification says: >>> "If Recursive is FALSE, then this function returns after all drivers >>> have been connected to ControllerHandle. If Recursive is TRUE, then >>> ConnectController() is called recursively on all of the child >>> controllers of ControllerHandle. The child controllers can be >>> identified by searching the handle database for all the controllers >>> that have opened ControllerHandle with an attribute of >>> EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER" >>> >>> So when I were seeking child controllers I should look for those who >>> have open with BY_CHILD_CONTROLLER on ControllerHandle. But which >>> protocol? All installed on ControllerHandle? >>> EFI_DRIVER_BINDING_PROTOCOL? >>> >> >> 1st what are you trying to do, the answer may be different. >> > > You only don't laugh at me, what I'm trying to do is to implement > ConnectController() as part of my UEFI implementation. And I was > asking from the perspective of ConnectController() function. >
Thanks that helps a lot. >> The relationship is tracked by meta data associated with the handle. You can >> use the EFI Boot Service OpenProtocolInformation() to get more info. You can >> use LocateHandleBuffer(), ProtocolsPerHandle(), and >> OpenProtocolInformation() to dump out the entire Handle/Protocol database. >> The edk2 Shell has some useful commands for showing this relationship so you >> might start there if you want to see the code, or you can use the shell >> commands to show you the relationship. There is a spec for the UEFI Shell is >> located here: http://www.uefi.org/specifications >> > > I meant this: what protocol interface (installed on the > ControllerHandle handle) ConnectController() function should check out > to find its (ControllerHandle's) children (when doing recursive > connection on it)? > Because BY_CHILD_CONTROLLER is an attribute of a protocol interface > opening on a handle. What the handle is, is clear, not so for the > protocol involved. I'm sure it's easy, but only for a skilled Uefi > specification guru. > If you are writing the implementation then you should be able to track the information? These are the data structures used to manage the handle/protocol database. https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Hand/Handle.h#L24 >From 10,000 feet.. The edk2 uses circular linked lists, LIST_ENTRY, to make >common operations simple. Each internal handle structure is in a list of all >handle, and has a list of the protocols on the handle (this is the internal >protocol structure interface). Each protocol interface has a back pointer to >the handle, and it is also in some other lists. it is a little to complicated >to describe in words but the idea is to cross index the information to make it >easier to implement. To find the children you walk the protocols on the handle list. For each protocol interface you walk the list of Open Protocol data and check the attribute, EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER. That gives you access to the information you need. A simpler way to say it is if you implement OpenProtocol keep a list of the open protocols that indexes back into the protocol database. >>> Next, I hope I understood right, but I'm not sure. Suppose >>> ConnectController finds a driver in the highest precedence group, let >>> it be the first - Context Override, it calls Supported() on that >>> driver (handle) and it returns SUCCESS, and then it calls Start() and >>> that returns SUCCESS. Should ConnectController stop trying all the >>> rest candidates for ControllerHandle after that? >> >> I'm not sure what you are asking? From a driver point of view it should not >> matter you just produce the Driver Binding Supported()/Start()/Stop(). The >> UEFI spec defines the precedence rules and that is the behavior you can >> depend on. When exactly Supported() gets called could be implementation >> dependent. The driver that gets the Start() call is deterministic. The best >> thing to do is assume Supported() gets call a lot and to be as efficient as >> possible. > > I should write what I'm trying to do from the beginning, now you know. > I was asking exactly about the behaviour of ConnectController() after > Start() success. Despite it looks obvious, the specification is > somewhat not clear about it, namely, when ConnectController() gets the > first EFI_SUCCESS from the Start() routine of the highest possible (in > the precedence order) Driver Binding protocol instance on a candidate > driver handle, should ConnectController() stop trying the next driver > or not? Logically it should stop, but honestly, (re)reading the > specification doesn't give confidence about this. > For any given situation there is only one driver to Start(). But after you call Start() and it returns EFI_SUCESS you need to check again as protocol and handles could have been added to the system by the driver. Simple Example: We start with a handle with a protocol on it. Handle - Prot A Call ConnectController() on it and Start() on the best match Handle - Prot A - Prot B We then call ConnectController() on it again and call Start() on the best match. Handle - Prot A - Prot B - Prot C. So basically driver 1 consumes A and produce B. Driver 2 consumes B and produce C. Bus drivers work the same way, but they create handles. >> This is the edk2 implementation of ConnectController(): >> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Hand/DriverSupport.c#L50 >> > > Thank you, I'm sure I'd get a lot of understanding by browsing the > code of an implementation. > To be honest untill now I was trying to avoid doing so, trying to look > only into the specification. > We can't complain about that. The edk2 source open source project is not related to the UEFI Forum but some of us do both. Thanks, Andrew Fish >> I'd also point out that doing a "connect all", calling ConnectController() >> on all the handles in the system. Would cause a drivers Supported() routine >> to get called a lot in a short period of time. >> >> Thanks, >> >> Andrew Fish >> > > Thank you for the asnwers and the links. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
