On 09/23/13 15:37, Olivier Martin wrote: > Contributed-under: TianoCore Contribution Agreement 1.0
> diff --git a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf > b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf > new file mode 100644 > index 0000000..e6deccb > --- /dev/null > +++ b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf > @@ -0,0 +1,43 @@ > +## @file > +# This driver produces the VirtIo Device Protocol instances for VirtIo Mmio > +# Device > +# > +# Copyright (C) 2013, ARM Ltd > +# > +# This program and the accompanying materials are licensed and made available > +# under the terms and conditions of the BSD License which accompanies this > +# distribution. The full text of the license may be found at > +# http://opensource.org/licenses/bsd-license.php > +# > +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, > WITHOUT > +# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. > +# > +## > + > +[Defines] > + INF_VERSION = 0x00010005 > + BASE_NAME = VirtioMmioDeviceLib > + FILE_GUID = 3b6ed966-b5d1-46a8-965b-867ff22d9c89 > + MODULE_TYPE = UEFI_DRIVER > + VERSION_STRING = 1.0 > + LIBRARY_CLASS = VirtioMmioDeviceLib Just a preliminary question -- why is the virtio-mmio implementation of the protocol a library, instead of a driver binary? Normally, under the driver model, some Supported() function should be called back, and it should identify a virtio-mmio capable device. The approach taken in patch #9 and #10 seems to be: - add a new DXE driver that basically does nothing to an ARM platform, - install a vendor device path on the new driver's ImageHandle that contains the UEFI executable's GUID (from patch #9, fe61bb5f-1b67-4c24-b346-73db42e873e5) -- BTW, EFI_CALLER_ID_GUID seems to be EFI 1 heritage. - using the virtio-mmio library, install the virtio-mmio implementation of the protocol on the ImageHandle. Hm. It's apparently impossible to detect, in a Supported() function, if a given handle stands for a virtio-mmio device. More precisely, there's no such handle at all -- the entire *platform* is virtio-mmio, not just some enumerated device / handle that has a bunch of protocols installed to it. OK. Second, the INF file says above, MODULE_TYPE=UEFI_DRIVER. According to the INF spec: The MODULE_TYPE entry in the [Defines] section for a library only defines the module type that the build system must assume for building the library. It does not define the types of modules that a library may be linked with. Instead, the LIBRARY_CLASS entry in the [Defines] section optionally lists the supported module types that the library may be linked against. So, the build system must "assume the UEFI_DRIVER module type for building the library", whatever that means. FWIW the client module (in patch #9) is DXE_DRIVER. I have no clue if these should match or not. Laszlo ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
