Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> Sent: 24 November 2015 17:24
> To: Paul Durrant
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Stefano Stabellini; Ian Campbell; Wei Liu
> Subject: RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for
> ~/control/shutdown
> 
> Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir()
> for ~/control/shutdown"):
> > [Ian Jackson:]
> > > I'm not sure I follow this argument.  What did you think of my idea
> > > of renaming libxl__xs_mkdir to libxl__xs_mknode ?
> >
> > The issue, as I said, is the initial state of the node. If you use
> > XS_MKDIR then it is not guaranteed to be empty.
> 
> It is guaranteed to be empty if nothing ever wrote anything non-empty
> to it.  I think participants in xenstore protocols, and users of
> xenstore to store things, are entitled to assume that no-one writes
> nonempty values to nodes that aren't supposed to have nonempty values.
> 
> And even if the node did somehow end up with a nonempty value, nothing
> would break because no-one would read it.

Maybe. Personally I would have thought a toolstack would want to put things 
into a known state and XS_MKDIR just doesn't do that.

> 
> > If you use XS_WRITE then it is and I think that is the correct
> > semantic here (even though we happen to get away with it at the
> > moment). I'm happy with the function rename, but would you be happy
> > with the change in semantic?
> 
> XS_MKDIR creates missing parents, which XS_WRITE doesn't.
> 

According to the documentation it does: (from xenstore.txt)

READ                    <path>|                 <value|>
WRITE                   <path>|<value|>
        Store and read the octet string <value> at <path>.
        WRITE creates any missing parent paths, with empty values.

  Paul

> Ian.

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