[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv) [and 1 more messages]
>>> On 21.09.16 at 19:09, <George.Dunlap@xxxxxxxxxxxxx> wrote: > On Wed, Sep 21, 2016 at 2:56 PM, Jan Beulich <JBeulich@xxxxxxxx> 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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |