[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |