From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: xenbus and the message of doom
Date: Tue, 20 Dec 2011 20:19:54 +0000
Message-ID: <1324412394.8252.163.camel@dagon.hellion.org.uk>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
	<1324375910.23729.31.camel@zakaz.uk.xensource.com>
	<20111220131533.GA7800@aepfle.de>	<20111220141612.GA25139@konrad-lan>
	<20208.50657.799146.57017@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <20208.50657.799146.57017@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, Olaf Hering <olaf@aepfle.de>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefan Bader <stefan.bader@canonical.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
List-Id: xen-devel@lists.xenproject.org

On Tue, 2011-12-20 at 17:29 +0000, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] xenbus and the message of doom"):
> > Sorry Olaf, have to revert that commit.
> 
> I agree.  When we introduced it we weren't aware that most existing
> implementations of xenstored simply ignore unknown commands rather
> than replying with an error.  If we had known this we would not have
> approved Olaf's patch.
> 
> That they ignore unknown commands is of course a bug but expecting
> everyone to update is no good.  Really the best approach would be some
> kind of discovery mechanism.
> 
> Maybe we should have a special path @xenstore/fail_unknown_commands
> which you could read, or something.  But this time we should try it
> against old implementations.

I was sure I'd seen some precedent (and therefore an existing path) for
this sort of thing at some point but I can't for the life of me find it.

The closest I could find is
the /local/domain/<N>/control/platform-feature-multiprocessor-suspend
node which we write statically for every domain. I suppose putting it
under /local/domain/<N> is consistent with restricting the domain to
mostly it's own home area.

Ian.