Re: [PATCH 2/3] xen/dmop: Strip __XEN_TOOLS__ header guard from public API

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.03.2021 15:12, Andrew Cooper wrote:
> On 05/03/2021 13:53, Jan Beulich wrote:
>> On 05.03.2021 13:49, Andrew Cooper wrote:
>>> Exactly as with c/s f40e1c52e4, this is inappropriate for a stable library.
>>>
>>> That change actually broke the build with:
>>>
>>>   include/xendevicemodel.h:52:5: error: unknown type name 'ioservid_t'
>>>        ioservid_t *id);
>>>        ^
>>>
>>> as libxendevicemodel.h now uses a type it can't see a typedef for.  However,
>>> nothing noticed because the header.chk logic is also broken (fixed
>>> subsequently).
>> While I agree up to here, ...
>>
>>> Strip the guard from the public header, and remove compensation from
>>> devicemodel's private.h
>> ... I'm unconvinced that entirely dropping the guard from the
>> public header is wanted (or needed): We use these to make clear
>> that in particular kernels aren't supposed to make use of the
>> enclosed entities. If a type needs exposing, it (and only it)
>> wants moving ou of the guarded region imo.
> 
> DMOP was invented specifically so a kernel module (i915, for Intel
> gVT-g) was independent of the domctl ABI version.
> 
> Improving the life of dom0 userspace was an intended consequence, but
> not the driving force behind the change.

This is news to me - so far it had been my understanding that it
was introduced to have a way for the kernel to audit and hand on
requests to the hypervisor without needing to know all the inner
details. I wasn't even aware a kernel module was using any of
these.

Jan