From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2743F21A00A1B for ; Thu, 18 May 2017 03:07:20 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 853D68046F; Thu, 18 May 2017 10:07:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 853D68046F Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 853D68046F Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-86.phx2.redhat.com [10.3.116.86]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1870117C5F; Thu, 18 May 2017 10:07:17 +0000 (UTC) To: Michael Zimmermann , Andrew Fish Cc: Mike Kinney , edk2-devel-01 , "Dong, Eric" , "Zeng, Star" References: <98D24FD3-B4DD-4132-BFA3-7D3887CA250D@apple.com> <37A305D9-9DD3-4D55-9E72-33219ABD8046@apple.com> From: Laszlo Ersek Message-ID: Date: Thu, 18 May 2017 12:07:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 18 May 2017 10:07:19 +0000 (UTC) Subject: Re: UEFI_DRIVER dependencies X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 10:07:20 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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