>>> On 21.09.16 at 19:09, wrote:
> On Wed, Sep 21, 2016 at 2:56 PM, Jan Beulich wrote:
>> Again this looks like much clutter with little benefit to me, i.e. I'd
>> then rather go with the unmodified original proposal. That's largely
>> because nothing really enforces anyone to use the (disconnect
On Wed, Sep 21, 2016 at 2:56 PM, Jan Beulich wrote:
> Again this looks like much clutter with little benefit to me, i.e. I'd
> then rather go with the unmodified original proposal. That's largely
> because nothing really enforces anyone to use the (disconnected)
> xen_dmop_foo_entry type. I.e. it
Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, re
qemu depriv) [and 1 more messages]"):
> On 21.09.16 at 15:24, wrote:
> > Would this be enough of an improvement, for you, to be worth the
> > additional type name clutter etc. ?
>
>>> On 21.09.16 at 15:24, wrote:
> Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP,
> re qemu depriv) [and 1 more messages]"):
>> On 21.09.16 at 14:23, wrote:
>> > But changes in the contents of the specific struct /wil
Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, re
qemu depriv) [and 1 more messages]"):
> On 21.09.16 at 14:23, wrote:
> > But changes in the contents of the specific struct /will/ be spotted.
>
> As long as it is a structure, yes. Wh
>>> On 21.09.16 at 14:23, wrote:
> Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP,
> re qemu depriv)"):
>> Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP,
>> > So the actual hypercall call sites are all in-tree, in libxc. If the
>> > for
Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, re
qemu depriv)"):
> Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP,
> > So the actual hypercall call sites are all in-tree, in libxc. If the
> > format of the struct used for one of these g
