From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.172]) (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 CE59321A16EFD for ; Wed, 17 May 2017 23:44:23 -0700 (PDT) Received: from [195.245.230.51] by server-12.bemta-3.messagelabs.com id 81/85-11537-5C24D195; Thu, 18 May 2017 06:44:21 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRWlGSWpSXmKPExsViZ8MxRfeok2y kwcceMYvptx+zWOw5dJTZYvOLYIuOjn9MFnOnPmW12Ndr7cDmsfXkDzaPnbPusnss3vOSyaN7 9j+WAJYo1sy8pPyKBNaM81/uMxUs86t49lq3gfGRYxcjJ4eQQCuTxLTLnF2MXED2MUaJz8862 CGci4wSPTdes4NUsQm4Slz8tw7I5uAQEYiU6P2UClLDLLCdUeJG91EmkLiwgI7Eru3+IOUiAr oS647PYoawjSTmffgOZrMIqEq0XN7CClLOK+AvsWQrL8Sqt8wSO76fAVvFKWAr8fb0VSYQm1F ARWLX3S2MIDazgLjEpmffWUFsCQEBiSV7zjND2KISLx//g4obSGxduo8FwlaQOLThKAtEr4HE +3PzmSFsbYllC1+D2bwCghInZz5hmcAoNgvJillIWmYhaZmFpGUBI8sqRo3i1KKy1CJdIzO9p KLM9IyS3MTMHF1DA2O93NTi4sT01JzEpGK95PzcTYzAiKxnYGDcwdiw1+8QoyQHk5Ior+s/mU ghvqT8lMqMxOKM+KLSnNTiQ4wyHBxKEryXHGUjhQSLUtNTK9Iyc4CpASYtwcGjJML7FCTNW1y QmFucmQ6ROsWoKCXOexgkIQCSyCjNg2uDpaNLjLJSwryMDAwMQjwFqUW5mSWo8q8YxTkYlYR5 N4JM4cnMK4Gb/gpoMRPQ4uYH0iCLSxIRUlINjMXF36UapX7aeSwJyFpS9XeF8hvXX+wrgo6x/ RcWFHtmrfDZyWjPwp4mnb4oy/WW+h3TS5ccDzycuK5/z8GUgmOH5s1LXiK3s/HUU64DV1VPyk V82q/381rFfnWH8NWfnHYa8z34yT39cfzJqKtPvppEJ2W0WDUGxL/5zvZ606SsVcYCE7TO6Cq xFGckGmoxFxUnAgDO26F2QgMAAA== X-Env-Sender: peter.kirmeier@ts.fujitsu.com X-Msg-Ref: server-4.tower-33.messagelabs.com!1495089861!98218148!1 X-Originating-IP: [62.60.8.148] X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11005 invoked from network); 18 May 2017 06:44:21 -0000 Received: from unknown (HELO mailhost1.uk.fujitsu.com) (62.60.8.148) by server-4.tower-33.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 18 May 2017 06:44:21 -0000 Received: from R01UKEXCASM121.r01.fujitsu.local (ex2k13_121.fs.fujitsu.com [10.183.43.173]) by mailhost1.uk.fujitsu.com (8.14.5/8.14.5) with ESMTP id v4I6i8wI028929 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 May 2017 07:44:08 +0100 Received: from R01UKEXCASM124.r01.fujitsu.local (10.183.43.176) by R01UKEXCASM121.r01.fujitsu.local (10.183.43.173) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 18 May 2017 07:44:12 +0100 Received: from R01UKEXCASM124.r01.fujitsu.local ([fe80::a100:54d8:1c51:87b9]) by R01UKEXCASM124.r01.fujitsu.local ([fe80::a100:54d8:1c51:87b9%23]) with mapi id 15.00.1263.000; Thu, 18 May 2017 07:44:13 +0100 From: "peter.kirmeier@ts.fujitsu.com" To: Andrew Fish , Michael Zimmermann CC: Mike Kinney , edk2-devel-01 , "Dong, Eric" , "Zeng, Star" Thread-Topic: [edk2] UEFI_DRIVER dependencies Thread-Index: AQHSz6CsDueEOJuv2kmWOQWLr5kozKH5o8wA Date: Thu, 18 May 2017 06:44:12 +0000 Message-ID: References: <98D24FD3-B4DD-4132-BFA3-7D3887CA250D@apple.com> <37A305D9-9DD3-4D55-9E72-33219ABD8046@apple.com> In-Reply-To: Accept-Language: de-DE, en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.182.185.8] MIME-Version: 1.0 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:44:24 -0000 Content-Language: de-DE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, just a short question here: Isn't the Supported() method of the Driver Bind= ing Protocol the place where one have to check the availabilities and depen= dencies? As long the dependencies are not fulfilled the respective error code is ret= urned until some other driver's Start() installed the required protocols an= d the own Support() method can then return success (and actually get Start(= )ed) ? Best Regards, Peter -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Andr= ew Fish Sent: Thursday, May 18, 2017 8:33 AM To: Michael Zimmermann Cc: Mike Kinney; edk2-devel-01; Dong, Eric; Zeng, Star Subject: Re: [edk2] UEFI_DRIVER dependencies > On May 17, 2017, at 11:25 PM, Michael Zimmermann wrote: >=20 > Andrew, doesn't that only address the case where an UEFI_DRIVER has depen= dencies 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_DR= IVER this way without relying on the fdf-order or using the device binding = mechanism. >=20 > 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 thu= s doesn't use the binding mechanism to bind to a device. >=20 Micheal, To get a little pedantic a UEFI driver could run on a system that did not s= upport PI and thus no dispatcher. The early Itanium systems worked this way= for example.=20 So if you are really a UEFI driver then you have to gBS->RegisterProtocolNo= tify() to deal with sequence of protocols that don't follow the EFI Driver = Model.=20 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 examp= le Depex and it would work the same way as a UEFI_DRIVER. You could then ad= d your extra Depex.=20 Thanks, Andrew Fish > Thanks, > Michael >=20 > On Thu, May 18, 2017 at 8:16 AM, Andrew Fish > wrote: > Michael, >=20 > I forgot to mention If the DXE phase does not produce all the protocols r= equired to dispatch UEFI_DRIVERs you get a lot of DEBUG prints and an ASSER= Ts out of the DXE Core.=20 >=20 > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Dx > eMain/DxeMain.c#L480=20 > xeMain/DxeMain.c#L480> >=20 > // > // Display Architectural protocols that were not loaded if this is DEBU= G build > // > DEBUG_CODE_BEGIN (); > CoreDisplayMissingArchProtocols (); > DEBUG_CODE_END (); >=20 > // > // Display any drivers that were not dispatched because dependency expr= ession > // evaluated to false if this is a debug build > // > DEBUG_CODE_BEGIN (); > CoreDisplayDiscoveredNotDispatched (); > DEBUG_CODE_END (); >=20 > // > // Assert if the Architectural Protocols are not present. > // > Status =3D CoreAllEfiServicesAvailable (); > if (EFI_ERROR(Status)) { > // > // Report Status code that some Architectural Protocols are not prese= nt. > // > REPORT_STATUS_CODE ( > EFI_ERROR_CODE | EFI_ERROR_MAJOR, > (EFI_SOFTWARE_DXE_CORE | EFI_SW_DXE_CORE_EC_NO_ARCH) > ); =20 > } > ASSERT_EFI_ERROR (Status); >=20 >=20 >> On May 17, 2017, at 11:09 PM, Andrew Fish > wrote: >>=20 >>>=20 >>> On May 17, 2017, at 10:42 PM, Michael Zimmermann > wrote: >>>=20 >>> Michael, that's a good point but it only works for drivers which=20 >>> bind to a device. If you're just installing a protocol e.g. for=20 >>> virtual devices or special services which you don't want to turn=20 >>> into libraries then this doesn't work. >>>=20 >>> Haojian, that's what I was thinking, I just wasn't sure if the order=20 >>> is reliable. >>>=20 >>=20 >> Micheal, >>=20 >> From a PI/UEFI architectural perspective the contract is the depex are h= onored. If multiple drivers are TRUE at the same time the order they execut= e 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 i= s the only architectural way to force order of dispatch. Well DXE has BEFOR= E and AFTER.=20 >>=20 >> When I wrote the original dispatcher I ended up adding new drivers to th= e tail of the list vs. the head. Both would have been legal from a spec poi= nt of view. So by observing the current behavior you are conflating my impl= ementation choice with the contract provided by specification.=20 >>=20 >>=20 >>> Andrew, your description sounds like its about DXE_DRIVERs and their=20 >>> Depex sections, does this apply to UEFI_DRIVERs too when they're=20 >>> auto-loaded from the fdf(since they don't support the Depex section)? >>>=20 >>=20 >> No Depex section for UEFI_DRIVERS implies this Depex: >>=20 >> [Depex] >> gEfiSecurityArchProtocolGuid AND=20 >> gEfiCpuArchProtocolGuid AND=20 >> gEfiMetronomeArchProtocolGuid AND=20 >> gEfiTimerArchProtocolGuid AND=20 >> gEfiBdsArchProtocolGuid AND=20 >> gEfiWatchdogTimerArchProtocolGuid AND=20 >> gEfiRuntimeArchProtocolGuid AND=20 >> gEfiVariableArchProtocolGuid AND=20 >> gEfiVariableWriteArchProtocolGuid AND=20 >> gEfiCapsuleArchProtocolGuid AND=20 >> gEfiMonotonicCounterArchProtocolGuid AND=20 >> gEfiResetArchProtocolGuid AND=20 >> gEfiRealTimeClockArchProtocolGuid =20 >>=20 >> This is how we glued PI (DXE_DRIVERS) and UEFI (UEFI_DRIVER) together. E= FI predates the concept of DXE in PI.=20 >>=20 >> 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= .=20 >>=20 >> Thanks, >>=20 >> Andrew Fish >>=20 >>> Thanks for all your answers, >>> Michael >>>=20 >>> On Thu, May 18, 2017 at 7:21 AM, Andrew Fish > wrote: >>>>=20 >>>>> On May 17, 2017, at 10:00 PM, Kinney, Michael D > wrote: >>>>>=20 >>>>> Michael, >>>>>=20 >>>>> The UEFI Driver Model and the Driver Binding Protocol provide=20 >>>>> support for this case. The idea is that a driver is loaded and=20 >>>>> started, but when a UEFI Driver is started, it only registers a=20 >>>>> Driver Binding Protocol. Then in the BDS phase, the devices=20 >>>>> required to boot are started using the UEFI Boot Service=20 >>>>> ConnectController() and >>>>> ConnectController() calls the Driver Binding Protocol(s). >>>>>=20 >>>>> The dependencies between UEFI Drivers are in their Driver Binding=20 >>>>> Protocols which are not used until after all of the UEFI Drivers=20 >>>>> are loaded and started. >>>>>=20 >>>>=20 >>>> Micheal, >>>>=20 >>>> 1st off no dependency is really a dependency on all the architecture p= rotocols, which is a fancy way of saying all the EFI Boot and Runtime Servi= ces are available. >>>>=20 >>>> Lets say you have a driver that depends on DiskIo. The DiskIo driver d= epends on BlockIo. Now what happens when a disk driver is connected and pro= duces a BlockIO is the DiskIo driver can know get connected. The DXE Core k= nows a protocol was added to the handle so it will keep trying to connect d= rivers to that handle as long as new protocols get added. So this is how th= e DriverBinding Support() is used to resolve the sequence issues. >>>>=20 >>>> Thanks, >>>>=20 >>>> Andrew Fish >>>>=20 >>>>> Mike >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org=20 >>>>>> ] On Behalf Of Michael=20 >>>>>> Zimmermann >>>>>> Sent: Wednesday, May 17, 2017 9:43 PM >>>>>> To: edk2-devel-01 >>>>> >; Zeng, Star=20 >>>>>> >; Dong, Eric=20 >>>>>> > >>>>>> Subject: [edk2] UEFI_DRIVER dependencies >>>>>>=20 >>>>>> I know that UEFI_DRIVERs don't need or support Depex sections,=20 >>>>>> but what if an UEFI_DRIVER depends on a protocol provided by=20 >>>>>> another UEFI_DRIVER? >>>>>> Since they get loaded automatically because I put them in my=20 >>>>>> platform's fdf, it raises the question of the loading order. >>>>>>=20 >>>>>> Will they get loaded in the order they're defined? How often will=20 >>>>>> the core retry if one of the drivers returns EFI_NOT_READY? >>>>>>=20 >>>>>> Thanks, >>>>>> Michael >>>>>> _______________________________________________ >>>>>> edk2-devel mailing list >>>>>> edk2-devel@lists.01.org =20 >>>>>> https://lists.01.org/mailman/listinfo/edk2-devel=20 >>>>>> >>>>> _______________________________________________ >>>>> edk2-devel mailing list >>>>> edk2-devel@lists.01.org =20 >>>>> https://lists.01.org/mailman/listinfo/edk2-devel=20 >>>>> >>>>=20 >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org =20 >>> https://lists.01.org/mailman/listinfo/edk2-devel=20 >>> >>=20 >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org =20 >> https://lists.01.org/mailman/listinfo/edk2-devel=20 >> >=20 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel