From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
"Paul Durrant" <paul@xen.org>, "Ian Jackson" <iwj@xenproject.org>,
Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/3] xen/dmop: Strip __XEN_TOOLS__ header guard from public API
Date: Fri, 5 Mar 2021 14:12:51 +0000 [thread overview]
Message-ID: <68a69e57-66b5-6f59-39f4-40649112fe40@citrix.com> (raw)
In-Reply-To: <9b4acfc5-6d96-7922-7fde-5d0d543f8201@suse.com>
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
next prev parent reply other threads:[~2021-03-05 14:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 12:49 [PATCH for-4.15 0/3] tools/libs: Multiple fixes to header handling Andrew Cooper
2021-03-05 12:49 ` [PATCH 1/3] tools/libxentoolcore: Fill in LIBHEADERS Andrew Cooper
2021-03-05 13:25 ` Ian Jackson
2021-03-11 13:37 ` Jürgen Groß
2021-03-05 12:49 ` [PATCH 2/3] xen/dmop: Strip __XEN_TOOLS__ header guard from public API Andrew Cooper
2021-03-05 13:26 ` Ian Jackson
2021-03-05 13:53 ` Jan Beulich
2021-03-05 14:12 ` Andrew Cooper [this message]
2021-03-05 14:18 ` Jan Beulich
2021-03-05 14:21 ` Jan Beulich
2021-03-05 15:13 ` Andrew Cooper
2021-03-05 15:20 ` Ian Jackson
2021-03-05 14:28 ` Ian Jackson
2021-03-05 12:49 ` [PATCH 3/3] tools/libs: Fix headers.chk logic Andrew Cooper
2021-03-05 13:38 ` Andrew Cooper
2021-03-05 13:43 ` Ian Jackson
2021-03-11 13:38 ` Jürgen Groß
2021-03-11 13:28 ` Ping [PATCH for-4.15 0/3] tools/libs: Multiple fixes to header handling Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=68a69e57-66b5-6f59-39f4-40649112fe40@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=iwj@xenproject.org \
--cc=jbeulich@suse.com \
--cc=paul@xen.org \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).