From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Dunlap <dunlapg@umich.edu>
Cc: Wei Liu <wei.liu2@citrix.com>,
StefanoStabellini <stefano.stabellini@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
mpohlack@amazon.de, Ross Lagerwall <ross.lagerwall@citrix.com>,
Julien Grall <julien.grall@arm.com>,
Stefano Stabellini <stefano.stabellini@citrix.com>,
Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>,
sasha.levin@oracle.com, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
KeirFraser <keir@xen.org>
Subject: Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
Date: Tue, 12 Apr 2016 09:56:38 -0400 [thread overview]
Message-ID: <20160412135637.GC27920@localhost.localdomain> (raw)
In-Reply-To: <CAFLBxZZuE-dwB+N9BGKDKzeQHQ+EfNtBpvjtE7i+gTr4jEhUpQ@mail.gmail.com>
On Tue, Apr 12, 2016 at 10:58:09AM +0100, George Dunlap wrote:
> On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich <JBeulich@suse.com> wrote:
> [snip]
> >> ISTM that the lower duplication (which in principle is an advantage
> >> which will be time limited if we are ever able to completely remove
> >> teh old hypercall) comes with the cost of (in the long term) increased
> >> mess in this particular subop.
> >
> > We cannot, ever, remove a not toolstack limited hypercall completely
> > (or if, then only by Kconfig option so that people knowing none of the
> > guests they care about use such deprecated ones).
>
> We need to keep the hypercall around and functioning for ABI
> compatibility, but we could at least remove it from the public headers
> and point people to using the new one instead. (Discussion about the
> merit of this idea below.)
>
> [snip]
> >> ISTM that the lower duplication (which in principle is an advantage
> >> which will be time limited if we are ever able to completely remove
> >> teh old hypercall) comes with the cost of (in the long term) increased
> >> mess in this particular subop.
> >>
> >> Is that right ? Obviously this cost is not very significant. But
> >> maybe the duplication isn't that significant either. I was kind of
> >> expecting to find stronger arguments on both sides in this
> >> discussion...
> >
> > If, btw, the cost of having to read the length argument from guest
> > memory was deemed undesirable, we'd certainly have the option
> > of specifying it to be passed through, say, the high half of the
> > current "cmd" parameter.
>
> OK, so here are the options I see:
>
> 1. Use the existing hypercall with the existing call semantics for
> build-id -- i.e., require the caller to have a large but fixed-length
> buffer (maybe 1024 or 2048).
>
> 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?"
You can't wedge in the extra argument. Tried that an Jan pointed out
that we clobber it (specifically we clobber any non-used arguments).
>
> 3. We could use a new hypercall only for new functionality, with the
> proposed new semantics. This would at minimum be build-id, but
> probably also extraversion, compileinfo, changeset, maybe
> capabilities_info.
>
> 4. Have the new hypercall replace the old hypercall. The new
> hypercall will duplicate all the functionality of the old hypercall.
> Deprecate the hypercall for a release or two, then remove it from the
> public headers (although keep the code, because we need to maintain
> backwards compatibility).
5). Stick the build-id in the xsplice sysctl. Or just in the sysctl.
>
> Honestly I still don't quite understand what the problem is with #1 --
> if build-id is mainly meant to be a UUID or a hash of the build to
> make sure that you're applying the right hotfix (please correct me if
> I'm wrong here -- I haven't had time to actually follow the patch
> series), 256 bytes should be enough for a properly hashed build, and
> 2048 should be more than enough. Requiring the caller to have a
> 2048-byte buffer before calling doesn't really seem like that much of
> a hardship to me. Basically:
>
> a. It's nicer to have arbitrary-length strings (2-4), but reasonably
> large fixed-length ones aren't awful (1)
>
> b. It's nicer for hypercall consumers to have a single hypercall with
> consistent semantics (1,4), but having two hypercalls (3) or a single
> one with inconsistent semantics (2) aren't that bad either.
>
> c. It's nicer for hypervisor maintainers to have a single place to
> support any given bit of functionality (1-3), but having a slightly
> duplicated functionality that only has to be supported in an ABI
> backwards-compatible manner isn't that bad either (4).
>
> This does seem to me an awful lot like a bike shed. :-) All of the
This is really past bike shedding - all the bikes shed have been
already built (for all those options).
> options (1-4) seem perfectly fine to me. FWIW my preferred color
> would probably be 1 because it's the easiest and least inconsistent
> with the current state of things. My least favorite would be 3,
> because although each individual piece of information is only in one
> place, the path to get there is duplicated; both the kernel developer
> and the hypervisor developer are forced to continue to deal with both.
>
The state is that 1-3 have been Nacked by Andrew, 4 has been
Nacked by Jan. And 5) (the original way) was way way back Nacked
as well.
I believe this conversation is to break a tie-breaker between maintainers.
(See http://www.xenproject.org/governance.html, Refereeing).
That is any of the REST maintainers or Project Leads will override the
Nack/Acks. Granted, Jan, me, and Andrew are excluded as we are most
certainly not neutral. That means Ian, Tim, and Keir.
And then we all can go to the pub.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-04-12 13:56 UTC|newest]
Thread overview: 190+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane Konrad Rzeszutek Wilk
2016-03-24 20:22 ` Andrew Cooper
2016-03-24 21:07 ` Konrad Rzeszutek Wilk
2016-03-24 21:30 ` Konrad Rzeszutek Wilk
2016-03-30 15:43 ` Jan Beulich
2016-03-31 6:30 ` Jan Beulich
2016-03-31 11:43 ` Konrad Rzeszutek Wilk
2016-03-31 12:07 ` Jan Beulich
2016-03-31 13:28 ` REST MAINTAINERS feedback requested Was:Re: " Konrad Rzeszutek Wilk
2016-03-31 13:50 ` Jan Beulich
2016-04-08 16:33 ` Jan Beulich
2016-04-08 17:09 ` Konrad Rzeszutek Wilk
2016-04-08 17:13 ` Jan Beulich
2016-04-08 17:21 ` Wei Liu
2016-04-08 17:23 ` Konrad Rzeszutek Wilk
2016-04-08 17:27 ` Wei Liu
2016-04-08 17:21 ` Ian Jackson
2016-04-08 17:41 ` Andrew Cooper
2016-04-08 17:54 ` Jan Beulich
2016-04-11 10:50 ` Ian Jackson
2016-04-11 13:56 ` Konrad Rzeszutek Wilk
2016-04-11 14:22 ` Ian Jackson
2016-04-11 15:48 ` Jan Beulich
2016-04-11 16:25 ` Ian Jackson
2016-04-11 16:53 ` Konrad Rzeszutek Wilk
2016-04-11 17:06 ` Jan Beulich
2016-04-11 17:00 ` Jan Beulich
2016-04-11 17:13 ` Ian Jackson
2016-04-11 17:34 ` Jan Beulich
2016-04-11 17:46 ` Jan Beulich
2016-04-12 9:58 ` George Dunlap
2016-04-12 13:56 ` Konrad Rzeszutek Wilk [this message]
2016-04-12 14:38 ` George Dunlap
2016-04-12 15:00 ` Konrad Rzeszutek Wilk
2016-04-12 15:26 ` Ian Jackson
2016-04-13 4:21 ` Jan Beulich
2016-04-13 16:07 ` Ian Jackson
2016-04-14 15:13 ` George Dunlap
2016-04-14 15:59 ` Jan Beulich
2016-04-14 16:19 ` George Dunlap
2016-04-14 17:01 ` Jan Beulich
2016-04-14 18:11 ` REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane. [and 1 more messages] Ian Jackson
2016-04-14 19:22 ` Konrad Rzeszutek Wilk
2016-04-17 7:23 ` Jan Beulich
2016-04-15 11:23 ` REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane George Dunlap
2016-04-17 7:52 ` Jan Beulich
2016-04-12 15:31 ` Jan Beulich
2016-04-12 15:17 ` Jan Beulich
2016-04-12 15:28 ` Konrad Rzeszutek Wilk
2016-04-08 17:24 ` George Dunlap
2016-04-08 17:34 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 02/28] libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall Konrad Rzeszutek Wilk
2016-03-24 21:24 ` Wei Liu
2016-03-25 13:21 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 03/28] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables lookup Konrad Rzeszutek Wilk
2016-03-30 16:09 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb Konrad Rzeszutek Wilk
2016-03-30 16:24 ` Jan Beulich
2016-03-30 16:44 ` Konrad Rzeszutek Wilk
2016-03-31 6:46 ` Jan Beulich
2016-03-31 11:49 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 05/28] xsplice: Design document Konrad Rzeszutek Wilk
2016-03-29 9:36 ` Jan Beulich
2016-03-29 20:46 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 06/28] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op Konrad Rzeszutek Wilk
2016-03-31 9:45 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 07/28] libxc: Implementation of XEN_XSPLICE_op in libxc Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 08/28] xen-xsplice: Tool to manipulate xsplice payloads Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 09/28] xsplice: Add helper elf routines Konrad Rzeszutek Wilk
2016-03-31 12:03 ` Jan Beulich
2016-04-06 1:38 ` Konrad Rzeszutek Wilk
2016-04-07 0:38 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 10/28] xsplice: Implement payload loading Konrad Rzeszutek Wilk
2016-03-31 13:45 ` Jan Beulich
2016-03-31 21:26 ` Konrad Rzeszutek Wilk
2016-04-01 9:18 ` Jan Beulich
2016-04-04 19:44 ` Konrad Rzeszutek Wilk
2016-04-05 1:57 ` Konrad Rzeszutek Wilk
2016-04-05 7:34 ` Jan Beulich
2016-04-05 15:50 ` Konrad Rzeszutek Wilk
2016-04-05 16:15 ` Jan Beulich
2016-04-05 16:45 ` Konrad Rzeszutek Wilk
2016-04-05 17:48 ` Konrad Rzeszutek Wilk
2016-04-07 0:49 ` Jan Beulich
2016-04-07 0:46 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches Konrad Rzeszutek Wilk
2016-04-01 13:28 ` Jan Beulich
2016-04-01 21:04 ` Konrad Rzeszutek Wilk
2016-04-04 7:07 ` Jan Beulich
2016-04-07 3:05 ` Konrad Rzeszutek Wilk
2016-04-07 15:38 ` Jan Beulich
2016-04-09 14:42 ` Konrad Rzeszutek Wilk
2016-04-11 15:38 ` Jan Beulich
2016-04-07 3:09 ` Konrad Rzeszutek Wilk
2016-04-07 15:43 ` Jan Beulich
2016-04-10 2:36 ` Konrad Rzeszutek Wilk
2016-04-10 2:45 ` Konrad Rzeszutek Wilk
2016-04-11 15:41 ` Jan Beulich
2016-04-11 23:29 ` Konrad Rzeszutek Wilk
2016-04-10 19:47 ` Is: ARM maintainers advice ..Was:Re: " Konrad Rzeszutek Wilk
2016-04-10 20:58 ` Stefano Stabellini
2016-04-11 15:44 ` Jan Beulich
2016-04-11 15:50 ` Konrad Rzeszutek Wilk
2016-04-11 16:05 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 12/28] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version' Konrad Rzeszutek Wilk
2016-04-01 13:33 ` Jan Beulich
2016-04-06 2:03 ` Konrad Rzeszutek Wilk
2016-04-07 1:03 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address Konrad Rzeszutek Wilk
2016-04-01 15:11 ` Jan Beulich
2016-04-07 3:14 ` Konrad Rzeszutek Wilk
2016-04-07 15:46 ` Jan Beulich
2016-04-08 1:32 ` Konrad Rzeszutek Wilk
2016-04-08 15:21 ` Jan Beulich
2016-04-08 15:27 ` Konrad Rzeszutek Wilk
2016-04-08 15:29 ` Jan Beulich
[not found] ` <5707D68A.8090006@citrix.com>
[not found] ` <5707FA8B02000078000E6178@prv-mh.provo.novell.com>
2016-04-11 8:07 ` Ross Lagerwall
2016-03-24 20:00 ` [PATCH v5 14/28] x86, xsplice: Print payload's symbol name and payload name in backtraces Konrad Rzeszutek Wilk
2016-04-01 15:23 ` Jan Beulich
2016-04-06 2:39 ` Konrad Rzeszutek Wilk
2016-04-07 1:07 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case Konrad Rzeszutek Wilk
2016-04-01 15:50 ` Jan Beulich
2016-04-06 2:42 ` Konrad Rzeszutek Wilk
2016-04-06 6:39 ` Martin Pohlack
2016-04-07 1:15 ` Jan Beulich
2016-04-08 15:57 ` Ross Lagerwall
2016-04-08 17:39 ` Jan Beulich
2016-04-11 8:23 ` Ross Lagerwall
2016-04-22 13:33 ` Jan Beulich
2016-04-22 13:58 ` Jan Beulich
2016-04-22 17:32 ` Konrad Rzeszutek Wilk
2016-04-07 1:11 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 16/28] xsplice: Add support for bug frames Konrad Rzeszutek Wilk
2016-04-01 16:00 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 17/28] xsplice: Add support for exception tables Konrad Rzeszutek Wilk
2016-04-01 16:06 ` Jan Beulich
2016-04-06 14:41 ` Konrad Rzeszutek Wilk
2016-04-06 15:32 ` Andrew Cooper
2016-04-07 1:21 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 18/28] xsplice: Add support for alternatives Konrad Rzeszutek Wilk
2016-04-01 16:20 ` Jan Beulich
2016-04-07 3:11 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 19/28] build_id: Provide ld-embedded build-ids Konrad Rzeszutek Wilk
2016-04-04 12:46 ` Jan Beulich
2016-04-07 2:58 ` Konrad Rzeszutek Wilk
2016-04-08 15:49 ` Ross Lagerwall
2016-04-08 18:47 ` Konrad Rzeszutek Wilk
2016-04-08 18:54 ` Andrew Cooper
2016-04-08 19:54 ` Jan Beulich
2016-04-08 0:18 ` Konrad Rzeszutek Wilk
2016-04-08 1:52 ` Konrad Rzeszutek Wilk
2016-04-08 15:27 ` Jan Beulich
2016-04-08 17:06 ` Konrad Rzeszutek Wilk
2016-04-08 17:44 ` Jan Beulich
2016-04-08 19:23 ` Konrad Rzeszutek Wilk
2016-04-08 19:39 ` Konrad Rzeszutek Wilk
2016-04-08 20:14 ` Jan Beulich
2016-04-08 20:50 ` Konrad Rzeszutek Wilk
2016-04-08 21:11 ` Jan Beulich
2016-04-08 21:15 ` Konrad Rzeszutek Wilk
2016-04-08 15:25 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 20/28] HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id Konrad Rzeszutek Wilk
2016-03-25 16:26 ` Daniel De Graaf
2016-04-04 13:35 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 21/28] libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id Konrad Rzeszutek Wilk
2016-03-25 13:25 ` Konrad Rzeszutek Wilk
2016-03-25 15:27 ` Wei Liu
2016-03-24 20:00 ` [PATCH v5 22/28] xsplice: Print build_id in keyhandler and on bootup Konrad Rzeszutek Wilk
2016-04-04 13:38 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 23/28] xsplice: Stacking build-id dependency checking Konrad Rzeszutek Wilk
2016-04-04 15:00 ` Jan Beulich
2016-04-04 20:01 ` Konrad Rzeszutek Wilk
2016-04-05 7:43 ` Jan Beulich
2016-04-08 16:15 ` Ross Lagerwall
2016-04-08 17:47 ` Jan Beulich
2016-04-06 20:05 ` Konrad Rzeszutek Wilk
2016-04-07 1:24 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 24/28] xsplice/xen_replace_world: Test-case for XSPLICE_ACTION_REPLACE Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 25/28] xsplice: Print dependency and payloads build_id in the keyhandler Konrad Rzeszutek Wilk
2016-04-04 15:03 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 26/28] xsplice: Prevent duplicate payloads from being loaded Konrad Rzeszutek Wilk
2016-04-04 15:06 ` Jan Beulich
2016-04-04 19:52 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 27/28] xsplice: Add support for shadow variables Konrad Rzeszutek Wilk
2016-04-04 15:18 ` Jan Beulich
2016-04-06 2:26 ` Konrad Rzeszutek Wilk
2016-04-08 15:58 ` Ross Lagerwall
2016-03-24 20:00 ` [PATCH v5 28/28] MAINTAINERS/xsplice: Add myself and Ross as the maintainers Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160412135637.GC27920@localhost.localdomain \
--to=konrad.wilk@oracle.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=dunlapg@umich.edu \
--cc=julien.grall@arm.com \
--cc=keir@xen.org \
--cc=mpohlack@amazon.de \
--cc=ross.lagerwall@citrix.com \
--cc=sasha.levin@oracle.com \
--cc=stefano.stabellini@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).