Re: Device model operation hypercall (DMOP, re qemu depriv) [and 1 more messages]

["Jan Beulich" <JBeulich@suse.com>]

>>> On 21.09.16 at 19:09, <George.Dunlap@eu.citrix.com> wrote:
> On Wed, Sep 21, 2016 at 2:56 PM, Jan Beulich <JBeulich@suse.com> 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 continues to be a matter of the
>> programmer's and the reviewers' attention/discipline.
> 
> But is "Must use hypercall dmop, subop foo with struct dmop_foo" any
> different than "Must use hypercall bar with struct bar"?
> 
> In theory there could be a mismatch between the struct libxc expected
> to use for a whole hypercall with the struct Xen expected to find for
> an entire hypercall. But in practice that never happens because we set
> up the call with the appropriate struct once and then never change it.

Yes.

> (That is, we may change the struct elements, but not the name.)  This
> seems to me like a fairly similar case.

I don't think so - what I'm talking about here is the equivalent of
"we may change the struct elements". Such changes would go
unnoticed by the compiler the respective pseudo-struct-element
is a handle.

But anyway - I think we've beaten this horse to death, and I'm the
only one worried about type issues here. Therefore I think we
should just stop this discussion and go with the proposed model.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel