public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Michael Zimmermann <sigmaepsilon92@gmail.com>
To: Andrew Fish <afish@apple.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>,
	"Zeng, Star" <star.zeng@intel.com>,
	"Dong, Eric" <eric.dong@intel.com>,
	Mike Kinney <michael.d.kinney@intel.com>
Subject: Re: UEFI_DRIVER dependencies
Date: Thu, 18 May 2017 07:42:16 +0200	[thread overview]
Message-ID: <CAN9vWDJzi2n2vn2ODeZ4Krid1AY80B895=HfvnS6wMhm90pQbg@mail.gmail.com> (raw)
In-Reply-To: <98D24FD3-B4DD-4132-BFA3-7D3887CA250D@apple.com>

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.

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)?

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] 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
>


  reply	other threads:[~2017-05-18  5:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18  4:43 UEFI_DRIVER dependencies Michael Zimmermann
2017-05-18  4:51 ` Haojian Zhuang
2017-05-18  5:00 ` Kinney, Michael D
2017-05-18  5:21   ` Andrew Fish
2017-05-18  5:42     ` Michael Zimmermann [this message]
2017-05-18  6:09       ` Andrew Fish
2017-05-18  6:16         ` Andrew Fish
2017-05-18  6:25           ` Michael Zimmermann
2017-05-18  6:29             ` Zeng, Star
2017-05-18  6:33             ` Andrew Fish
2017-05-18  6:44               ` peter.kirmeier
2017-05-18  6:56                 ` Andrew Fish
2017-05-18 10:07             ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAN9vWDJzi2n2vn2ODeZ4Krid1AY80B895=HfvnS6wMhm90pQbg@mail.gmail.com' \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox