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. Exactly the same is true for stubdoms currently, and I am very serious about purging unstable interfaces eventually. ~Andrew
