On 23.08.2022 17:56, Bertrand Marquis wrote: >> On 23 Aug 2022, at 16:45, Jan Beulich <jbeul...@suse.com> wrote: >> On 23.08.2022 17:09, Bertrand Marquis wrote: >>> How about moving those to a xen-acpi.h header and include that one in xen.h >>> ? >> >> In principle okay, if there wasn't the need for HVM_MAX_VCPUS. With a >> suitable comment it may be okay to live there. I'd be curious what >> others think. > > The problem with this already exists in the current status as this is defined > in > hvm_info_table.h which is never included from arch-x86/xen.h
You're referring to it being necessary to explicitly include both headers. That's not what I'm referring to, though: The tool imo shouldn't include hvm_info_table.h, and hence the HVM_MAX_VCPUS would need to move as well. > Including hvm_info_table.h from xen-acpi.h could create include path issues. Include path issues? Both are / would be public headers. But as said, I don't think any new header introduced for the purpose at hand should include _any_ other public header. > But as those are used nowhere apart from mk_dsdt, I would probably skip the > include of xen-acpi.h from xen.h. Hmm, yes, that's reasonable I guess as far as XEN_ACPI_* go. Of course HVM_MAX_VCPUS is a different matter. > Any chance that those XEN_ACPI_ are needed by some external tools that > could get broken by this modification ? Requiring them to include another header is, I think, a tolerable form of breakage, the more that such breakage isn't very likely anyway. Jan
