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 48A8521A16EFB for ; Wed, 17 May 2017 23:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1495087786; 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=dujnO6G+j9eP+Sr1rO8iu1A93CDOO2MFdFsS7THYDk8=; b=ndSOhksV9Z9frMJLWDDH7Pd/8tTcPeSccWoeCgIV3gtdif2PFtTwtwilEVROOQ1m LRA5IUHRFKh5wtc9oMg1DE7nitVvplI9+SInnLW7gQytNwOxFqfyVdWTGGZ6UW2w DdN5wySQva+DTC0+SXw23VfVEJGPSKta4Ht8CDw6fsC3SwkxJhdN3GYW3Leesqpu GPpBe/dSKgxmCqzP3EEnSVqStudyAxXgJe5OuXIAbTntCLifGL31oJccMEfTiIor 9XFZd8xA0DMNWoGEP59Jc4lv36JFhs0011V8PQFMbe2BgDWN4D+XSsVXaGgLzZv/ wptOKn25rf2ivEGrAw/syw==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (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 4F.4E.26227.9AA3D195; Wed, 17 May 2017 23:09:46 -0700 (PDT) X-AuditID: 11973e15-0b9fb70000006673-65-591d3aa954fb Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay2.apple.com (Apple SCV relay) with SMTP id AB.D3.07829.9AA3D195; Wed, 17 May 2017 23:09:45 -0700 (PDT) MIME-version: 1.0 Received: from [17.153.32.91] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OQ400HEZX48R830@nwk-mmpp-sz10.apple.com>; Wed, 17 May 2017 23:09:45 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: Date: Wed, 17 May 2017 23:09:44 -0700 Cc: Mike Kinney , edk2-devel-01 , "Dong, Eric" , "Zeng, Star" Message-id: <37A305D9-9DD3-4D55-9E72-33219ABD8046@apple.com> References: <98D24FD3-B4DD-4132-BFA3-7D3887CA250D@apple.com> To: Michael Zimmermann X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUi2FDorLvKSjbSYFM/j8WeQ0eZLTa/CLbo 6PjHZDF36lNWi3291g6sHjtn3WX3WLznJZNH9+x/LAHMUVw2Kak5mWWpRfp2CVwZ3U0H2Qr+ aVTc+9bN1sD4SqGLkZNDQsBEYtPFbtYuRi4OIYHVTBLnD+1khEn0XZnKDpE4xChxa8tGJpAE r4CgxI/J91i6GDk4mAXkJQ6elwUJMwtoSXx/1MoCUf+FUWJBdx8LSEJYQFzi3ZlNzBC2jsTU hefYQWw2AWWJFfM/gNmcAsESv7cvBpvPIqAqcfTKXCaI+QuBFsdBrLWR2Ni8kRli/jQmicnr frKCJEQEDCWeNj9mgjhaVuLW7EtgRRICB9gk/i87xzSBUXgWkrtnIdw9C8ndCxiZVzEK5SZm 5uhm5pnpJRYU5KTqJefnbmIEhf90O9EdjGdWWR1iFOBgVOLh3RAkEynEmlhWXJl7iFGag0VJ nDd0M1BIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD45yAMouzNzqunZizvPnS5zn+8zf48zYp Wx39/iBS9dr9Fhme8gmvFvHla1o9OXMqKThzbXv1f66Ydp9s7YY3GSFSSU8aZO5GO2gvnJEQ Nj/BroXZY1u2hNc7k9UnQpOehmTb79nweF5c72+/th3yrw3/HZ+u8/aN2yKPsyffNaf23n/2 JI1VVImlOCPRUIu5qDgRACSWuLdgAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUi2FBcpbvSSjbS4OFrZYs9h44yW2x+EWzR 0fGPyWLu1KesFvt6rR1YPXbOusvusXjPSyaP7tn/WAKYo7hsUlJzMstSi/TtErgyupsOshX8 06i4962brYHxlUIXIyeHhICJRN+VqexdjFwcQgKHGCVubdnIBJLgFRCU+DH5HksXIwcHs4C8 xMHzsiBhZgEtie+PWlkg6r8wSizo7mMBSQgLiEu8O7OJGcLWkZi68Bw7iM0moCyxYv4HMJtT IFji9/bFYPNZBFQljl6ZywQxfyHQ4jiItTYSG5s3MkPMn8YkMXndT1aQhIiAocTT5sdMEEfL StyafYl5AqPALCSnzkI4dRaSUxcwMq9iFChKzUmsNNJLLCjISdVLzs/dxAgO10LnHYzHllkd YhTgYFTi4d0QJBMpxJpYVlyZCwwLDmYlEd7pFrKRQrwpiZVVqUX58UWlOanFhxirgO6fyCwl mpwPjKW8knhDExMDE2NjM2NjcxNzqggrifM+FgfaLJCeWJKanZpakFoEs5yJg1OqgdHiVNGO Ods32ul5dDKKMLcwu2iaKi5yOX6x4otT5pyXB85tjSrXr1q+aPaSxss3+yfE614w5PVYNmGC 6RnvW539HUbRDM2f+gwtctOrPWb4Zkf45U9vVFFSjp90Pr1t14lT15/Xa8xYtNf1XG+kSxnf gznaM16f/K6sf21iQFa8QO3aug+PXiuxFGckGmoxFxUnAgCT2pNcsgIAAA== 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:09:47 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > 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