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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
