From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A849021A16EFD for ; Wed, 17 May 2017 23:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1495089198; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+hCDvRFIpMB/3wckW3p7uZcLXqHuNH/S7GEOdy2FtNk=; b=rimSzUvVWUpVzsn703OAJ6LiLie9vXaEM5lA7UqRewzGuIbzRbEIZr+wys3VyMFY ukD7FCdKwEw/wPG7VD1Q2Nrwpz0etZ4karKFpw6hP3BsKiC/jMyhumMPEnn1it25 tev/RVbxK5pZ3CRGcmI8Soue9qgneOB+bSKjjw0aJOaUL7/Y+g2IwBR2thjU81Sj 1Xwz6bAMuei/7WLqGHbLGhdGvKlsG8jUXhhfkswqzpnxs3K8SnwVk5NLhIoSnJVw pRKbc+cXOIuPz7X5D4tNMCJGBZS8r0C1loDiJ1Mdo0Wn7avS6SyN4KldmsP6LIgy 03Ljy+rWnz6ob5gWb2hdrA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id AD.CF.26227.E204D195; Wed, 17 May 2017 23:33:18 -0700 (PDT) X-AuditID: 11973e15-5b52c9a000006673-dc-591d402ecf74 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay5.apple.com (Apple SCV relay) with SMTP id 78.80.02326.D204D195; Wed, 17 May 2017 23:33:17 -0700 (PDT) MIME-version: 1.0 Received: from [17.153.32.91] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OQ400HZKY7G8U00@nwk-mmpp-sz12.apple.com>; Wed, 17 May 2017 23:33:17 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: Date: Wed, 17 May 2017 23:33:16 -0700 In-reply-to: Cc: Mike Kinney , edk2-devel-01 , "Dong, Eric" , "Zeng, Star" To: Michael Zimmermann References: <98D24FD3-B4DD-4132-BFA3-7D3887CA250D@apple.com> <37A305D9-9DD3-4D55-9E72-33219ABD8046@apple.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUi2FAYoavnIBtpsPi1kMWeQ0eZLTa/CLbo 6PjHZDF36lNWi3291g6sHjtn3WX3WLznJZNH9+x/LAHMUVw2Kak5mWWpRfp2CVwZj+e8ZS24 t4ml4uq2M4wNjMvaWLoYOTkkBEwkrl6azQxiCwmsZpJ4O6UeJt7X2QoU5wKKH2KUOPpsEytI gldAUOLH5HtgzcwCYRIbF8+GKvrCKLF/+hsmkISwgLjEuzObwKayCShLrJj/gb2LkQOo2Uai f3kVRImOxNSF59hBbBYBVYk3b26ygZRwCgRL9H61ATGZBRYyStyKA6kQETCUeNr8mAli02Fm ic/rz7JB3CkrcWv2JbATJAQes0lsXrCEaQKj0Cwkp85CciqErSXx/VErUBxkh7zEwfOyEGFN iWf3PrFD2NoST95dYF3AyLaKUSg3MTNHNzPPTC+xoCAnVS85P3cTIyheptuJ7mA8s8rqEKMA B6MSD++GIJlIIdbEsuLK3EOM0hwsSuK8oZuBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhd 4oWaa3skGeOFqkoNqiM+Bc7a9GTz5vfvZM2bHnPH3o/VmbA9ahsjz6uWQB3WbKW3UZVimesa mhe0/XS0WLVN+W+tbLSKi/CcCmM7b7cO58ZlxyZPfCd8OeFGLk8Kx7zVsesWMFR+bPVf3nK1 81XftEVySy5pPNtuUW28/8RuKa/nC+WeTVFiKc5INNRiLipOBAAzJHlDeAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAIsWRmVeSWpSXmKPExsUi2FB8RlfXQTbSoP2NgcWeQ0eZLTa/CLbo 6PjHZDF36lNWi3291g6sHjtn3WX3WLznJZNH9+x/LAHMUVw2Kak5mWWpRfp2CVwZj+e8ZS24 t4ml4uq2M4wNjMvaWLoYOTkkBEwk+jpbmbsYuTiEBA4xShx9tokVJMErICjxY/I9sCJmgTCJ jYtnQxV9YZTYP/0NE0hCWEBc4t2ZTcwgNpuAssSK+R/Yuxg5gJptJPqXV0GU6EhMXXiOHcRm EVCVePPmJhtICadAsETvVxsQk1lgIaPErTiQChEBQ4mnzY+ZIDYdZpb4vP4sG8SdshK3Zl9i nsDIPwvJdbOQXAdha0l8f9QKFAcZKy9x8LwsRFhT4tm9T+wQtrbEk3cXWBcwsq1iFChKzUms NNVLLCjISdVLzs/dxAgO8MKIHYz/l1kdYhTgYFTi4d0YJBMpxJpYVlyZCwwiDmYlEd7pFrKR QrwpiZVVqUX58UWlOanFhxgnMgL9OJFZSjQ5Hxh/eSXxhiYmBibGxmbGxuYm5rQUVhLnfSQO dJFAemJJanZqakFqEcxRTBycUg2MvM2+/19/Flp8SCnl012vyyp6wXIZpnoPjZr81/wpXLrw f9E2RacOpmmLdhw3e1h1nVlPQ+meoSiPeotpVKlY5FLO+q/9p6S73Nd8jzp6+kzk1j/vxWax FRjpLvyq69j0RPWmcharyKkAuS61cqNl93VlZ+9at4Az+eJ+PqN109v/5q1W5HNUYinOSDTU Yi4qTgQATHTWVeMCAAA= X-Content-Filtered-By: Mailman/MimeDel 2.1.22 Subject: Re: UEFI_DRIVER dependencies X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 06:33:18 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > On May 17, 2017, at 11:25 PM, Michael Zimmermann wrote: > > Andrew, doesn't that only address the case where an UEFI_DRIVER has dependencies on certain dxe drivers?(which, as you said will always be available). > It's still unclear to me how an UEFI_DRIVER can depend on another UEFI_DRIVER this way without relying on the fdf-order or using the device binding mechanism. > > My usecase is that I want to install a protocol from within a uefi driver which then can be used by other uefi drivers. It's a pure protocol and thus doesn't use the binding mechanism to bind to a device. > Micheal, To get a little pedantic a UEFI driver could run on a system that did not support PI and thus no dispatcher. The early Itanium systems worked this way for example. So if you are really a UEFI driver then you have to gBS->RegisterProtocolNotify() to deal with sequence of protocols that don't follow the EFI Driver Model. If you want to have a DEPEX then you are really a DXE_DRIVER (UEFI + PI). I guess you could take a UEFI_DRIVER rename it a DXE_DRIVER and add my example Depex and it would work the same way as a UEFI_DRIVER. You could then add your extra Depex. Thanks, Andrew Fish > Thanks, > Michael > > On Thu, May 18, 2017 at 8:16 AM, Andrew Fish > wrote: > Michael, > > I forgot to mention If the DXE phase does not produce all the protocols required to dispatch UEFI_DRIVERs you get a lot of DEBUG prints and an ASSERTs out of the DXE Core. > > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c#L480 > > // > // Display Architectural protocols that were not loaded if this is DEBUG build > // > DEBUG_CODE_BEGIN (); > CoreDisplayMissingArchProtocols (); > DEBUG_CODE_END (); > > // > // Display any drivers that were not dispatched because dependency expression > // evaluated to false if this is a debug build > // > DEBUG_CODE_BEGIN (); > CoreDisplayDiscoveredNotDispatched (); > DEBUG_CODE_END (); > > // > // Assert if the Architectural Protocols are not present. > // > Status = CoreAllEfiServicesAvailable (); > if (EFI_ERROR(Status)) { > // > // Report Status code that some Architectural Protocols are not present. > // > REPORT_STATUS_CODE ( > EFI_ERROR_CODE | EFI_ERROR_MAJOR, > (EFI_SOFTWARE_DXE_CORE | EFI_SW_DXE_CORE_EC_NO_ARCH) > ); > } > ASSERT_EFI_ERROR (Status); > > >> On May 17, 2017, at 11:09 PM, Andrew Fish > wrote: >> >>> >>> On May 17, 2017, at 10:42 PM, Michael Zimmermann > wrote: >>> >>> Michael, that's a good point but it only works for drivers which bind >>> to a device. If you're just installing a protocol e.g. for virtual >>> devices or special services which you don't want to turn into >>> libraries then this doesn't work. >>> >>> Haojian, that's what I was thinking, I just wasn't sure if the order >>> is reliable. >>> >> >> Micheal, >> >> From a PI/UEFI architectural perspective the contract is the depex are honored. If multiple drivers are TRUE at the same time the order they execute is not defined. Basically it is implementation choice and you should not write code that depends on this. This is why the A priori file exists, it is the only architectural way to force order of dispatch. Well DXE has BEFORE and AFTER. >> >> When I wrote the original dispatcher I ended up adding new drivers to the tail of the list vs. the head. Both would have been legal from a spec point of view. So by observing the current behavior you are conflating my implementation choice with the contract provided by specification. >> >> >>> Andrew, your description sounds like its about DXE_DRIVERs and their >>> Depex sections, does this apply to UEFI_DRIVERs too when they're >>> auto-loaded from the fdf(since they don't support the Depex section)? >>> >> >> No Depex section for UEFI_DRIVERS implies this Depex: >> >> [Depex] >> gEfiSecurityArchProtocolGuid AND >> gEfiCpuArchProtocolGuid AND >> gEfiMetronomeArchProtocolGuid AND >> gEfiTimerArchProtocolGuid AND >> gEfiBdsArchProtocolGuid AND >> gEfiWatchdogTimerArchProtocolGuid AND >> gEfiRuntimeArchProtocolGuid AND >> gEfiVariableArchProtocolGuid AND >> gEfiVariableWriteArchProtocolGuid AND >> gEfiCapsuleArchProtocolGuid AND >> gEfiMonotonicCounterArchProtocolGuid AND >> gEfiResetArchProtocolGuid AND >> gEfiRealTimeClockArchProtocolGuid >> >> This is how we glued PI (DXE_DRIVERS) and UEFI (UEFI_DRIVER) together. EFI predates the concept of DXE in PI. >> >> The primary job of DXE_DRIVERS is to configure all the hardware required to provide all the EFI Boot and Runtime Services. The above protocols are what the DXE Core requires to produce all the EFI Boot and Runtime services. >> >> Thanks, >> >> Andrew Fish >> >>> Thanks for all your answers, >>> Michael >>> >>> On Thu, May 18, 2017 at 7:21 AM, Andrew Fish > wrote: >>>> >>>>> On May 17, 2017, at 10:00 PM, Kinney, Michael D > wrote: >>>>> >>>>> Michael, >>>>> >>>>> The UEFI Driver Model and the Driver Binding Protocol >>>>> provide support for this case. The idea is that a driver >>>>> is loaded and started, but when a UEFI Driver is started, >>>>> it only registers a Driver Binding Protocol. Then in the >>>>> BDS phase, the devices required to boot are started using >>>>> the UEFI Boot Service ConnectController() and >>>>> ConnectController() calls the Driver Binding Protocol(s). >>>>> >>>>> The dependencies between UEFI Drivers are in their Driver >>>>> Binding Protocols which are not used until after all of >>>>> the UEFI Drivers are loaded and started. >>>>> >>>> >>>> Micheal, >>>> >>>> 1st off no dependency is really a dependency on all the architecture protocols, which is a fancy way of saying all the EFI Boot and Runtime Services are available. >>>> >>>> Lets say you have a driver that depends on DiskIo. The DiskIo driver depends on BlockIo. Now what happens when a disk driver is connected and produces a BlockIO is the DiskIo driver can know get connected. The DXE Core knows a protocol was added to the handle so it will keep trying to connect drivers to that handle as long as new protocols get added. So this is how the DriverBinding Support() is used to resolve the sequence issues. >>>> >>>> Thanks, >>>> >>>> Andrew Fish >>>> >>>>> Mike >>>>> >>>>>> -----Original Message----- >>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org ] On Behalf Of Michael >>>>>> Zimmermann >>>>>> Sent: Wednesday, May 17, 2017 9:43 PM >>>>>> To: edk2-devel-01 >; Zeng, Star >; Dong, >>>>>> Eric > >>>>>> Subject: [edk2] UEFI_DRIVER dependencies >>>>>> >>>>>> I know that UEFI_DRIVERs don't need or support Depex sections, but >>>>>> what if an UEFI_DRIVER depends on a protocol provided by another >>>>>> UEFI_DRIVER? >>>>>> Since they get loaded automatically because I put them in my >>>>>> platform's fdf, it raises the question of the loading order. >>>>>> >>>>>> Will they get loaded in the order they're defined? How often will the >>>>>> core retry if one of the drivers returns EFI_NOT_READY? >>>>>> >>>>>> Thanks, >>>>>> Michael >>>>>> _______________________________________________ >>>>>> edk2-devel mailing list >>>>>> edk2-devel@lists.01.org >>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>>> _______________________________________________ >>>>> edk2-devel mailing list >>>>> edk2-devel@lists.01.org >>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>> >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >