Andrew Cooper writes ("Re: [PATCH for-4.15 v2] xen/dmop: Strip __XEN_TOOLS__
header guard from public API"):
> On 11/03/2021 14:18, Roger Pau Monné wrote:
> > I think using __XEN_UNSTABLE_ABI__ would be way clearer than
> > __XEN_TOOLS__, or even placing those in a
On 11/03/2021 14:18, Roger Pau Monné wrote:
> On Thu, Mar 11, 2021 at 11:05:32AM +, Andrew Cooper wrote:
>> On 11/03/2021 08:27, Jan Beulich wrote:
>>> Depends on what __XEN_TOOLS__ really means - to guard things accessible
>>> to any part of the tool stack, or to guard unstable interfaces
On 11/03/2021 14:44, Jan Beulich wrote:
> On 11.03.2021 14:43, Andrew Cooper wrote:
>> On 11/03/2021 13:28, Jan Beulich wrote:
>>> On 11.03.2021 14:00, Andrew Cooper wrote:
However, having laid things out in this way today, it occurs to me that
we should consider further cleanup as well.
On Thu, Mar 11, 2021 at 01:43:05PM +, Andrew Cooper wrote:
> On 11/03/2021 13:28, Jan Beulich wrote:
> > On 11.03.2021 14:00, Andrew Cooper wrote:
> >> However, having laid things out in this way today, it occurs to me that
> >> we should consider further cleanup as well.
> >>
> >> I do agree
On 11.03.2021 14:43, Andrew Cooper wrote:
> On 11/03/2021 13:28, Jan Beulich wrote:
>> On 11.03.2021 14:00, Andrew Cooper wrote:
>>> However, having laid things out in this way today, it occurs to me that
>>> we should consider further cleanup as well.
>>>
>>> I do agree that code wanting to use
On Thu, Mar 11, 2021 at 11:05:32AM +, Andrew Cooper wrote:
> On 11/03/2021 08:27, Jan Beulich wrote:
> > Depends on what __XEN_TOOLS__ really means - to guard things accessible
> > to any part of the tool stack, or to guard unstable interfaces only.
>
> As far as I'm concerned, __XEN_TOOLS__
On 11/03/2021 13:28, Jan Beulich wrote:
> On 11.03.2021 14:00, Andrew Cooper wrote:
>> However, having laid things out in this way today, it occurs to me that
>> we should consider further cleanup as well.
>>
>> I do agree that code wanting to use the libxendevicemodel.h API almost
>> certainly
On 11.03.2021 14:00, Andrew Cooper wrote:
> However, having laid things out in this way today, it occurs to me that
> we should consider further cleanup as well.
>
> I do agree that code wanting to use the libxendevicemodel.h API almost
> certainly don't want/need the dmop ABI. (i.e. an
On 11/03/2021 11:41, Jan Beulich wrote:
> On 11.03.2021 12:05, Andrew Cooper wrote:
>> On 11/03/2021 08:27, Jan Beulich wrote:
>>> On 10.03.2021 18:22, Andrew Cooper wrote:
On 10/03/2021 17:12, Jan Beulich wrote:
> On 10.03.2021 16:07, Andrew Cooper wrote:
>> ---
On 11.03.2021 12:05, Andrew Cooper wrote:
> On 11/03/2021 08:27, Jan Beulich wrote:
>> On 10.03.2021 18:22, Andrew Cooper wrote:
>>> On 10/03/2021 17:12, Jan Beulich wrote:
On 10.03.2021 16:07, Andrew Cooper wrote:
> --- a/docs/designs/dmop.pandoc
> +++ b/docs/designs/dmop.pandoc
On 11/03/2021 08:27, Jan Beulich wrote:
> On 10.03.2021 18:22, Andrew Cooper wrote:
>> On 10/03/2021 17:12, Jan Beulich wrote:
>>> On 10.03.2021 16:07, Andrew Cooper wrote:
--- a/docs/designs/dmop.pandoc
+++ b/docs/designs/dmop.pandoc
@@ -4,9 +4,13 @@ DMOP
Introduction
On 10.03.2021 18:22, Andrew Cooper wrote:
> On 10/03/2021 17:12, Jan Beulich wrote:
>> On 10.03.2021 16:07, Andrew Cooper wrote:
>>> --- a/docs/designs/dmop.pandoc
>>> +++ b/docs/designs/dmop.pandoc
>>> @@ -4,9 +4,13 @@ DMOP
>>> Introduction
>>>
>>>
>>> -The aim of DMOP is to
On 10.03.2021 18:22, Andrew Cooper wrote:
> On 10/03/2021 17:12, Jan Beulich wrote:
>> On 10.03.2021 16:07, Andrew Cooper wrote:
>>> --- a/docs/designs/dmop.pandoc
>>> +++ b/docs/designs/dmop.pandoc
>>> @@ -4,9 +4,13 @@ DMOP
>>> Introduction
>>>
>>>
>>> -The aim of DMOP is to
On 10/03/2021 17:12, Jan Beulich wrote:
> On 10.03.2021 16:07, Andrew Cooper wrote:
>> --- a/docs/designs/dmop.pandoc
>> +++ b/docs/designs/dmop.pandoc
>> @@ -4,9 +4,13 @@ DMOP
>> Introduction
>>
>>
>> -The aim of DMOP is to prevent a compromised device model from compromising
>>
On 10.03.2021 16:07, Andrew Cooper wrote:
> --- a/docs/designs/dmop.pandoc
> +++ b/docs/designs/dmop.pandoc
> @@ -4,9 +4,13 @@ DMOP
> Introduction
>
>
> -The aim of DMOP is to prevent a compromised device model from compromising
> -domains other than the one it is providing
Andrew Cooper writes ("Re: [PATCH for-4.15 v2] xen/dmop: Strip __XEN_TOOLS__
header guard from public API"):
> Thanks, but you already release acked it. This is the requested update
> including the documentation change.
Oh yes so I did.
Ian.
On 10/03/2021 15:14, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH for-4.15 v2] xen/dmop: Strip __XEN_TOOLS__
> header guard from public API"):
>> Exactly as with c/s f40e1c52e4, this is inappropriate for a stable library.
>>
>> That change actually bro
Andrew Cooper writes ("[PATCH for-4.15 v2] xen/dmop: Strip __XEN_TOOLS__ header
guard from public API"):
> 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:
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.
19 matches
Mail list logo
