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 <[email protected]> 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 <[email protected]> wrote: > > > On May 17, 2017, at 10:42 PM, Michael Zimmermann <[email protected]> > 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 <[email protected]> wrote: > > > On May 17, 2017, at 10:00 PM, Kinney, Michael D < > [email protected]> 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:[email protected] > <[email protected]>] On Behalf Of Michael > Zimmermann > Sent: Wednesday, May 17, 2017 9:43 PM > To: edk2-devel-01 <[email protected]>; Zeng, Star < > [email protected]>; Dong, > Eric <[email protected]> > 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 > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > > > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
