>>> On 21.09.16 at 14:23, <ian.jack...@eu.citrix.com> 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
>> > format of the struct used for one of these guest handle slots changes,
>> > the same struct definition from the Xen headers is used both in the
>> > hypervisor and in libxc, and any incompatibility will be detected.
>> Wait, no. The guest handle slots in Jenny's proposal are basically
>> Each sub-op implies a certain type for each handle slot it actually
> Yes. But in practice each such slot will in practice be accessed by
> using copy_dm_buffer_from_guest (or whatever) to copy it to a struct.
> It is intended that that same struct type will be used by libxc to
> populate the buffer.
> Now, it is true that the compiler cannot check that the _same type_ is
> used in both places. So, as I say:
> It's true that changes to the semantics of these slots (for example, a
> change of a slot from "array of struct X" to "one struct Y") will not
> be detected by the compiler.
> 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?
>> but I do think that it failed to point out this downside,
>> which imo moves the balance between the two proposals.
> I'm afraid that I want to complain about this part of your approach to
> the thread, which I think is unduly harsh.
> It is of course fair to point out a potential downside of the proposal,
> which wasn't clearly discussed in the discussion document. And it is
> sensible for us all to consider that potential downside along with the
> others - as indeed I do above.
> But I don't think it is really fair to criticise *the discussion
> document* (which is what Jennifer's email was) on the grounds that it
> ommitted to discuss a potential downside which its authors felt was
Hmm, then I'm sorry if this came over the wrong way. I didn't
mean to criticize the document as a whole, or how it was written.
> The purpose of a discussion document is to put forward a
> proposal and/or summarise previous discussion. It is not required to
> be either neutral or, indeed, comprehensive - and even so, I found
> this one quite comprehensive.
Nevertheless I think such a document should be as honest as
possible wrt downsides of the (by the author(s)) preferred of
potentially multiple approaches. If some aspect is deemed minor,
I don't think it should be omitted (as then readers won't know
whether the aspect was considered at all), but mentioned and
stated to be believed to be minor.
Xen-devel mailing list