Re: UEFI_DRIVER dependencies

[Michael Zimmermann <sigmaepsilon92@gmail.com>]

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 <afish@apple.com> 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 <afish@apple.com> wrote:
>
>
> On May 17, 2017, at 10:42 PM, Michael Zimmermann <sigmaepsilon92@gmail.com>
> 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 <afish@apple.com> 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
> <edk2-devel-bounces@lists.01.org>] On Behalf Of Michael
> Zimmermann
> Sent: Wednesday, May 17, 2017 9:43 PM
> To: edk2-devel-01 <edk2-devel@lists.01.org>; Zeng, Star <
> star.zeng@intel.com>; Dong,
> Eric <eric.dong@intel.com>
> 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
>
>
>