Re: [PATCH v3 0/8] x86: compat header generation and checking adjustments

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.07.2020 06:33, Jürgen Groß wrote:
> On 23.07.20 17:45, Jan Beulich wrote:
>> As was pointed out by 0e2e54966af5 ("mm: fix public declaration of
>> struct xen_mem_acquire_resource"), we're not currently handling structs
>> correctly that have uint64_aligned_t fields. Patch 2 demonstrates that
>> there was also an issue with XEN_GUEST_HANDLE_64().
>>
>> 1: x86: fix compat header generation
>> 2: x86/mce: add compat struct checking for XEN_MC_inject_v2
>> 3: x86/mce: bring hypercall subop compat checking in sync again
>> 4: x86/dmop: add compat struct checking for 
>> XEN_DMOP_map_mem_type_to_ioreq_server
>> 5: evtchn: add compat struct checking for newer sub-ops
>> 6: x86: generalize padding field handling
>> 7: flask: drop dead compat translation code
>> 8: x86: only generate compat headers actually needed
>>
>> v3: Build fix for old gcc in patch 1. New patch 5.
> 
> Just an idea:
> 
> Instead of parsing an existing header and trying to create a compat
> header from it, assuming some special constructs and names, wouldn't it
> make more sense to have a common input file and create non-compat and
> compat headers (and the functions/macros to convert them into each
> other) from it?

Sounds like quite a bit of work, but if you or anyone else would
want to invest into trying this approach - why not? (Ideally
interfaces like our public ABI would imo best be described in IDL
or some such anyway, and per-language headers [or whatever the
language requires] then derived from it.)

The current approach was chosen back at the time to make it
sufficiently obvious that the introduction of the compat layer
had no negative impact on the native interface definitions.

> This would at once drop the need for compat checking
> and new interfaces could be tested automatically to not require a compat
> variant.

Not sure about this one: If a code path uses the native struct
even for handling the compat case, how would both layouts matching
be enforced without any explicit check somewhere?

Jan