From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] x86: add hypercall to querycurrentunderlying pCPU's frequency Date: Mon, 22 Sep 2008 10:24:03 +0100 Message-ID: References: <48D77EF3.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <48D77EF3.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org There's a paragraph at: http://www.xen.org/community/ Since the AB is involved in managing the Xen trademark, and this would be a decision which is part of defining what Xen is, I think the decision rests with them. Their address is xen-advisory-board at same list server as xen-devel. Also Novell is a member: I think the contact is Holger Dyroff. -- Keir On 22/9/08 10:18, "Jan Beulich" wrote: > 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). >> >> 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. > > >