>>> On 31.03.16 at 13:43, <kon...@kernel.org> wrote: > On Thu, Mar 31, 2016 at 12:30:09AM -0600, Jan Beulich wrote: >> >>> On 30.03.16 at 17:43, <jbeul...@suse.com> 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@lists.xen.org http://lists.xen.org/xen-devel