Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.03.16 at 13:43, <konrad@xxxxxxxxxx> wrote:
> On Thu, Mar 31, 2016 at 12:30:09AM -0600, Jan Beulich wrote:
>> >>> On 30.03.16 at 17:43, <JBeulich@xxxxxxxx> wrote:
>> > Since they're all cosmetic, if you take care of all of them, feel free
>> > to stick my ack on the result.
>> 
>> Actually - no, please don't. While the patch is fine content wise
>> then from my perspective, I'm still lacking a convincing argument
>> of why this new hypercall is needed in the first place. If others
>> are convinced by the argumentation between (mostly, iirc) you
>> and Andrew, I'm not going to stand in the way, but I'm also not
>> going to approve of the code addition without being myself
>> convinced.
> 
> Damm. I pushed the patch in yesterday in 'staging'!
> 
> We can always revert them..
> 
> "Others" being other maintainers I presume?

Any one of the REST maintainers, yes.

> The underlaying reason for me doing this is to expose the build-id.
> 
> It (build-id) originally was in sysctl, then folks wanted it in XENVER_.
> Got it working in there as sub-ops, but Andrew last minute decided that
> it should not really be there but in a new hypercall that can do
> three arguments (the length) and be able to return -EPERM. A sane
> one, not the cobbled up XENVER one.

Well, -EPERM is now possible with the old one too. And nothing
in that existing interface prevents a length to be passed in/out
for new sub-ops. Nor do I really see anything truly insane with
that existing interface.

Jan


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