From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] x86: add hypercall to querycurrentunderlying pCPU's frequency Date: Mon, 22 Sep 2008 10:18:11 +0100 Message-ID: <48D77EF3.76E4.0078.0@novell.com> References: <48D76BA3.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org What/who is the Advisory Board, and how would I forward the question to = it/them? Jan >>> Keir Fraser 22.09.08 10:47 >>> Well, I'm not personally against this, if used sensibly, but it sounds the sort of thing the Advisory Board would have to be asked about, since it could be considered to promote forking of the hypervisor interfaces. -- Keir On 22/9/08 08:55, "Jan Beulich" wrote: > Okay, in that case I'll have to raise a general infra-structural = question: If > I'm convinced I/we want something like this for ease of use and = consistency > with the native kernel, how would I (generally) add (sub-)hypercalls to > our Xen flavors without risking to ever collide with upstream? I'd = consider > something like using (reserving) the number space starting with e.g. = ASCII > 'NW' (a traditional Novell prefix) in the upper 16 bits, but of course = I'd > want to have formal insurance that this range would actually remain > reserved forever within each (sub-)hypercall ranges (and whatever else > may use [pseudo-]enumerated values). >=20 > Another alternative would obviously be to simply once again use an > enumeration of interested parties, who would then have a certain number > range globally (across all other [pseudo-]enumerations) reserved for = their > purposes, i.e. with the upper so-many bits set to that 'vendor' = enumerator.