> On May 17, 2017, at 11:25 PM, Michael Zimmermann <[email protected]> > wrote: > > 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. >
Micheal, To get a little pedantic a UEFI driver could run on a system that did not support PI and thus no dispatcher. The early Itanium systems worked this way for example. So if you are really a UEFI driver then you have to gBS->RegisterProtocolNotify() to deal with sequence of protocols that don't follow the EFI Driver Model. 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 example Depex and it would work the same way as a UEFI_DRIVER. You could then add your extra Depex. Thanks, Andrew Fish > Thanks, > Michael > > On Thu, May 18, 2017 at 8:16 AM, Andrew Fish <[email protected] > <mailto:[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 > > <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] >> <mailto:[email protected]>> wrote: >> >>> >>> On May 17, 2017, at 10:42 PM, Michael Zimmermann <[email protected] >>> <mailto:[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] >>> <mailto:[email protected]>> wrote: >>>> >>>>> On May 17, 2017, at 10:00 PM, Kinney, Michael D >>>>> <[email protected] <mailto:[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] >>>>>> <mailto:[email protected]>] On Behalf Of Michael >>>>>> Zimmermann >>>>>> Sent: Wednesday, May 17, 2017 9:43 PM >>>>>> To: edk2-devel-01 <[email protected] >>>>>> <mailto:[email protected]>>; Zeng, Star <[email protected] >>>>>> <mailto:[email protected]>>; Dong, >>>>>> Eric <[email protected] <mailto:[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] <mailto:[email protected]> >>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>>>> <https://lists.01.org/mailman/listinfo/edk2-devel> >>>>> _______________________________________________ >>>>> edk2-devel mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>>> <https://lists.01.org/mailman/listinfo/edk2-devel> >>>> >>> _______________________________________________ >>> edk2-devel mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.01.org/mailman/listinfo/edk2-devel >>> <https://lists.01.org/mailman/listinfo/edk2-devel> >> >> _______________________________________________ >> edk2-devel mailing list >> [email protected] <mailto:[email protected]> >> https://lists.01.org/mailman/listinfo/edk2-devel >> <https://lists.01.org/mailman/listinfo/edk2-devel> > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
