From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E47D421A16EFB for ; Wed, 17 May 2017 23:25:09 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id e55so5856489uaa.2 for ; Wed, 17 May 2017 23:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FZCvY0Lmx/ubhnN2ycmkXLKc6ovJBd6hep08YOY65+E=; b=veBac7/3GKo4PPQZjdmznbK0eoM8cx3UIE8gX7QULolQYGXzwjpy0DHGhnOtR9QWBH NrXbHEU9hm9wImsKBF4ofxPXzxJJQngfS41qFAzeh0C32ATOoQpvThisHiRIIaeNV7T0 vH7X2KigZBg5l49tUepoRXQ3aYI4vsCfJhscXGkb/QNIwa8ixwZqZGojw16pgfbqU6Ss 2twfFQ7cRZD4IbBmeIeHyq0AfFNR94MZrouuSwxgy6N0RspjMlPTVsF3ruXgBk1lyZK+ TFQkon86pIkdS/mmtKuVDy0tstDxYqZwiG9zH1OSHoi8L8pgvC+rnzfwOo7LjFYtRpfv XJaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FZCvY0Lmx/ubhnN2ycmkXLKc6ovJBd6hep08YOY65+E=; b=LyDzSTIhA1gHst7Aiz5kGxhzbFB6jtKLo/lT7ZZOfqcMIrI6lxlz1SKdp//5kYKUOl Jw8n/ozhanBUof6nbttzIg2oAcma3bCer6yp2rV+obQtOf8wtAcjtKMneitjErlHnlmy irvDAwz7PN94WANhc7dmxt9fJvRR0TeBylA2l0NWPSRtF1m8iFZCWRF3QA9uFwOwoIvX MkOqV1lHkbnNSCUyjrvOCecTAsCi74tXRgUwyLrnWyQNoF5CTfU8rH9iaLI9xCVc8Lkt S98FWiwR+WJ1TBnBFjW4yfIR38pdps3V2lxwlZfdvGo8Apw0arXT4u2t/EC3leaVBxUB JZBg== X-Gm-Message-State: AODbwcBW9wW4NnfH+gEJ1k1l+5PaV+IS2M5/X0h6h9Bo6RGtD+goc6m7 UrTeE4s63/LbMFICnpzV9qL3KXHdmQ== X-Received: by 10.176.81.28 with SMTP id e28mr1145350uaa.114.1495088709037; Wed, 17 May 2017 23:25:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.94.206 with HTTP; Wed, 17 May 2017 23:25:08 -0700 (PDT) In-Reply-To: References: <98D24FD3-B4DD-4132-BFA3-7D3887CA250D@apple.com> <37A305D9-9DD3-4D55-9E72-33219ABD8046@apple.com> From: Michael Zimmermann Date: Thu, 18 May 2017 08:25:08 +0200 Message-ID: To: Andrew Fish Cc: Mike Kinney , edk2-devel-01 , "Dong, Eric" , "Zeng, Star" 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:25:10 -0000 Content-Type: text/plain; charset="UTF-8" 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. 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 < > michael.d.kinney@intel.com> 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 < > star.zeng@intel.com>; 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 > > >