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. :) > 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. Does it actually cause problems if we include Virtio10.h from Virtio.h? -Jordan _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
