[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 0/4] docs: Document xenstore paths



> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> Sent: 13 November 2015 16:20
> To: Paul Durrant
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [PATCH v3 0/4] docs: Document xenstore paths
> 
> Paul Durrant writes ("RE: [Xen-devel] [PATCH v3 0/4] docs: Document
> xenstore paths"):
> > [Ian:]
> > > And the documents themselves should then clearly state what the
> > > behaviour should be on the part of a toolstack which finds the
> > > information missing, or set to a particular values.
> >
> > Yes, I think that would be useful to add. In trying to implement the
> > associated changed in libxl I can see it would be valuable :-)
> 
> Right.  In particular, your specification needs to be compatible with
> the current implementation in libxl, as well as with a future
> implementation which actually uses these new features :-).
> 
> > > Likewise, they should document the expected behaviour of a guest
> which
> > > finds that the entries are missing or cannot be written for
> > > permissions reasons.
> >
> > In general from the guest PoV there's not a lot it can do if a path
> > is not writable, but I'll call that out.
> 
> Right.  But presumably you want to say that the guest may (try to)
> write them even if they don't already exist (that's right, isn't it?),
> but that the guest MUST NOT fail just because it can't write them.
> 
> If it can't write them it should simply carry on (maybe making a note
> in an obscure and non-alarming logfile somewhere).
> 

Yes, that's exactly the intention. I'll add suitable text.

  Paul

> thanks,
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.