On 04/05/16 20:20, Jordan Justen wrote: > On 2016-04-05 11:06:39, Laszlo Ersek wrote: >> On 04/05/16 19:26, Jordan Justen wrote: >>> On 2016-04-05 09:46:33, Laszlo Ersek wrote: >>>> (I've snipped liberally below, but I've been careful to follow up on all >>>> of your comments.) >>>> >>>> On 04/05/16 18:08, Jordan Justen wrote: >>>>> On 2016-04-05 01:31:27, Laszlo Ersek wrote: >>>>>> On 04/05/16 09:03, Jordan Justen wrote: >>>>>>> On 2016-03-14 05:53:23, Laszlo Ersek wrote: >>>>>>>> These header files are intentionally minimal, and intentionally kept >>>>>>>> apart >>>>>>>> from the VirtIo 0.9.5 headers. >>>>>>>> >>>>>>>> Cc: Ard Biesheuvel <[email protected]> >>>>>>>> Cc: Jordan Justen <[email protected]> >>>>>>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>>>>>> Signed-off-by: Laszlo Ersek <[email protected]> >>>>>>>> --- >>>>>>>> OvmfPkg/Include/IndustryStandard/Virtio10.h | 81 >>>>>>>> ++++++++++++++++++++ >>>>>>>> OvmfPkg/Include/IndustryStandard/Virtio10Net.h | 31 ++++++++ >>>>>>>> 2 files changed, 112 insertions(+) >>>>>>>> >>>>>>>> diff --git a/OvmfPkg/Include/IndustryStandard/Virtio10.h >>>>>>>> b/OvmfPkg/Include/IndustryStandard/Virtio10.h >>>>>>>> new file mode 100644 >>>>>>>> index 000000000000..722475c4ea55 >>>>>>>> --- /dev/null >>>>>>>> +++ b/OvmfPkg/Include/IndustryStandard/Virtio10.h >>>>> >>>>> How about including Virtio10.h from Virtio.h? >>>> >>>> Okay... What for? Definitions exposed by either header do not depend on >>>> definitions from the other header. >>>> >>> >>> Once again, because this follows the example of Acpi.h and Pci.h... >> >> Wait a minute, that's not a good analogy. >> >> (a) Looking at Acpi.h and Pci.h, those are "catch-all" headers. They >> say, "if you include me, I'll give you everything ACPI (or everything >> PCI), across all versions of the relevant standards". >> >> (b) Furthermore, regarding any such header file there that concerns >> itself with a specific version of the PCI or ACPI specs, the header with >> the higher version number includes the header with the lower version number. >> >> Specifics: >> - Acpi.h -> Acpi61.h -> Acpi60.h -> Acpi51.h -> Acpi50.h -> ... >> - Pci.h -> Pci30.h -> Pci23.h -> Pci22.h >> -> PciExpress21.h >> -> PciExpress30.h -> PciExpress21.h (strange...) >> >> As I said, this is not a good analogy. Because: Virtio.h never wanted to >> be a catch-all header. To closely imitate the Acpi.h and Pci.h situation >> above, I would have to rename Virtio.h to Virtio095.h first, then >> include it in Virtio10.h, then introduce a *new* file called Virtio.h, >> which should include Virtio10.h. >> >> At the moment, Virtio.h is not the catch-all header, it is actually the >> base (= lowest version number) header. > > Yes, it currently is a catch-all header. It just happens that there is > only 1 version of the spec in the tree at the moment. :)
Good point. > >> So your suggestion would >> establish the inverse direction, compared to Acpi.h and Pci.h. >> >> Now, if you indeed proposed >> >> Virtio.h [new] -> Virtio10.h -> Virtio095.h [to be renamed from >> the current Virtio.h] >> >> then I would say, "a lot of churn for nothing". >> > > I think we should include 1.0 from Virtio.h, and determine if we want > to break out the Virtio095.h file at a later point. Works for me. > > Does it actually cause problems if we include Virtio10.h from > Virtio.h? No, it shouldn't; they are independent of each other. Note however that the same will not work for VirtioNet.h <-> Virtio10Net.h, because Virtio10Net.h already depends on (and includes) VirtioNet.h. Including Virtio10Net.h from VirtioNet.h would lead to a cycle. (The inclusion guards would prevent an actual inclusion loop, but the definition of VIRTIO_1_0_NET_REQ would not compile.) Thanks Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
