Re: [Xen-devel] xenbus and the message of doom

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-01-02 at 17:16 +0000, Olaf Hering wrote:
> On Tue, Dec 20, Ian Campbell wrote:
> 
> > 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.
> 
> 
> If you could come up with a patch to present xenstored (or other
> dom0/toolstack) features, that would be great.

As I said in the bit you trimmed the precedent seems to be to
write /local/domain/<N>/control/platform-feature-<X> for each guest that
you want to expose the feature to. I think a per-guest key makes sense
since even if something seems obviously global you never know when you
might need to hide it from a guest (e.g. to workaround an in-guest bug).

I'm afraid I don't have time to work on this myself but it seems pretty
simple?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel