Jan Beulich writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."): > George Dunlap <dunl...@umich.edu> 04/12/16 11:58 AM >>> > >2. Use the existing hypercall but wedge in different calling semantics > >for the build-id subop. We could have just that subop pay attention > >to an extra argument as a length, for example, and return an error if > >the length is too short. Or we could make essentially a flag that > >asks, "How much space if I were to execute this subop for real?" > > A suitable variant of this is what I've been arguing for.
Earlier I wrote: It's clear that there are various options, most of which are tolerable. Buit if I'm trying to help referee a disagreement between Andrew and Jan I would prefer to be choosing between Andrew's preferred answer and Jan's preferred answer. So as I see it we have two options actually seriously proposed: Andrew's new hypercall, and Jan's additional argument (in the struct, seems to be what Jan is mainly suggesting). The new hypercall is neater but more new code - and involves a deprecation plan; the additional argument is more messy but less duplication. I think either of these options is tolerable. I don't see the need to look further. Frankly, I find the choice difficult. But the bikeshed has to be painted /some/ colour and we should make these decisions in a sensible way and that means I and George (who've been called on to help decide) need to put forward an opinion. On balance I think I prefer Jan's suggestion, mostly on the grounds that in case of dispute, disagreement, or uncertainty, it is (all other things being equal) better to make smaller changes. And if this hypercall becomes _too_ much of a mess we can always replace it later along the lines that Andrew suggests. I look forward to hearing from George. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel