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

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

>>> On 21.09.16 at 15:24, <ian.jackson@eu.citrix.com> 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, <ian.jackson@eu.citrix.com> wrote:
>> > But changes in the contents of the specific struct /will/ be spotted.
>> 
>> As long as it is a structure, yes. What about someone changing
>> uint64_t to xen_pfn_t?
> 
> You mean if someone changes one of the buffers from "array of
> uint64_t" to "array of xen_pfn_t", so that the ABI changes on some but
> not all architectures ?
> 
> We could declare a rule that a dmop buffer may contain only a struct
> or type name specific to that dmop (or an array of such), and must
> always be accessed through a copy to or from such a type.
> 
> The rule would mean that if we had a dmop which wanted to call, using
> one of the buffers, a function like this:
> 
>      int some_function(uint64_t *pfns, size_t n_pfns);
> 
> You'd have to write the dmop definition like this:
> 
>      typedef uint64_t xen_dmop_foo_entry;
> 
>      xen_dmop_foo_entry *pfns;
>      size_t n_pfns;
> 
>      ...allocate table somehow...
>      ret = copy_dm_buffer_from_guest(pfns,
>                                      sizeof(pfns[0])*n_pfns,
>                                      buffers, nr_buffers, 1);
>      ...
>      ret = some_function(pfns, n_pfns);
> 
> And similar code, again using xen_dmop_foo_entry. on the calling side.
> Then if the buffer entry type is changed to xen_pfn_t you change it
> to:
> 
>      typedef xen_pfn_t xen_dmop_foo_entry;
> 
> Now, unless the rest of the code is changed too, the compiler will
> warn that a xen_pfn_t* cannot be converted to a uint64_t* in the call
> to some_function.  (And likewise at the hypercall site in libxc.)
> 
> Would this be enough of an improvement, for you, to be worth the
> additional type name clutter etc. ?

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.

Jan


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