Re: UEFI_DRIVER dependencies

[Laszlo Ersek <lersek@redhat.com>]

On 05/18/17 08:25, Michael Zimmermann 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.

I don't see why this should be a problem.

Your first driver should be a DXE driver (a platform driver) that
allocates a handle in its entry point function, installing the protocol
instance in question on it. Optionally, consider installing a device
path proto instalce on it as well, most likely with a single VenHw()
node (into which you can put any kind of administrative data you like,
just make sure you grab a fresh vendor GUID with uuidgen).

In turn, your second driver can be a UEFI driver that conforms to the
UEFI driver model. In the Supported() member of the driver binding
protocol, check for the presence of your custom protocol on the handle.
In ths Start() member, open the protocol "by driver".

In this case, the first driver exposes the protocol immediately at
dispatch, and the second driver consumes the protocol when its
Supported() and Start() members are called from within BDS.

We use the above method in practice for virtio-mmio, on ARM / AARCH64:

- ArmVirtPkg/VirtioFdtDxe is a platform driver that produces instances
  of the VIRTIO_DEVICE_PROTOCOL, using VirtioMmioDeviceLib. It is a DXE
  driver.
- In turn, all of the virtio device drivers consume
  VIRTIO_DEVICE_PROTOCOL.

Virtio-pci looks different. For that, we have VirtioPciDeviceDxe (for
legacy virtio) and Virtio10Dxe (for modern-only virtio). Both are UEFI
drivers themselves (operating on PCI IO protocol instances) and both
produce one VIRTIO_DEVICE_PROTOCOL instance per one PCI B/D/F bound. The
virtio device drivers are none the wiser about the actual virtio transport.


If your first driver *must* be a UEFI driver as well (for whatever
reason) that *also* conforms to the UEFI driver model (for whatever
reason), then in that driver, do two things in the enty point function:

(1) install the driver binding protocol instance that you produce
anyway, for UEFI driver model conformance,

(2) *also* do what I described above, for the DXE driver's entry point
function.

This way, when BDS calls into your second UEFI driver, for binding a
handle, the second driver will find the (singleton) protocol instance in
the protocol database, installed by the first driver's entry point
function at dispatch, *even if* the first UEFI driver hasn't bound any
handles yet.

Thanks
Laszlo