2016-05-27 23:30 GMT+03:00, Andrew Fish <[email protected]>: > >> 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. > >
Thank you. Now I see, we need to use all protocols installed on ControllerHandle to find children. I saw this in the ConnectController() implementation. By the way, it seems don't care about duplicates, right? So if the same child controller has opened (with the BY_CHILD_CONTROLLER attribute) two protocols on ControllerHandle, it would be added to the array twice. >> >> 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. > Thank you, as I've said I have looked at the ConnectController implementation and kind of understood its logic. What is very strange to me is that it possibly might return EFI_NOT_READY, (Single version of it), and thus repeating all again, NOT after Supported() or Start() called, but after ordered list of candidates building, - it calls LocateHandleBuffer() to find handles with the Driver Binding Prtocol instances on them, then it builds that list, then checks LocateHandleBuffer again, just to see if the number of handles with Driver Binding protocol installed has changed (why it should? this function could not be blocked, it works at TPL_NOTIFY, isn't it? who might install that protocol while the function was building its ordered list?) But what is more strange, and this is what I was asking about, the implementation works the way that even with Start() failed it stops trying next drivers. all it needs preceding Supported() returned SUCCESS. Then DriverFound is set TRUE, and the Single version stops looping. As a result it will not try the next driver handle at all. CoreConnectController will return NOT_FOUND (since OneStarted variable is set only on Start() success). It answers a lot for me, but brings a lot of confusion as well. But at least I understood what I was asking first. Thank you. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
