Re: [Xen-devel] [DOCDAY PATCH] docs: initial documentation for xenstore paths

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-09-24 at 12:35 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [DOCDAY PATCH] docs: initial documentation for 
> xenstore paths"):
> > On Thu, 2012-08-09 at 15:02 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [DOCDAY PATCH] docs: initial documentation for 
> > > xenstore paths"):
> > > ...
> > > > > --- a/docs/misc/xenstore-paths.markdown
> > > > > +++ b/docs/misc/xenstore-paths.markdown
> > > > > @@ -0,0 +1,294 @@
> > > ...
> > > > > +PATH can contain simple regex constructs following the POSIX regexp
> > > > > +syntax described in regexp(7). In addition the following additional
> > > > > +wild card names are defined and are evaluated before regexp 
> > > > > expansion:
> > > 
> > > Can we use a restricted perl re syntax ?  That avoids weirdness with
> > > the rules for \.
> > 
> > Is "restricted perl re syntax" a well defined thing (reference?) or do
> > you just mean perlre(1)--?
> 
> I mean pcre, or perlre(1), probably.
> 
> > What's the weirdness with \.?
> 
> In Perl syntax, a punctuation character preceded by \ is always a
> literal, and all metacharacters are unbackslashed punctuation.

Great, I think I can cope with that.

I suspect I've mostly used that syntax already anyhow.

> In regexp(7) you need to remember which of ( ) | [ ] . & $ need
> \-escaping to be literals and which need \-annotating to be
> metacharacters.  (And there are various dialects of this too; for
> example Emacs regexps require \ in front of a different subset of the
> punctuation.)

Yes, I don't think I've ever done a regexp search and replace in emacs
successfully on my first attempt.

> I don't particularly care about all the fancy (?:...) etc. extensions,
> but being able to write the regexp without referring to the manual, or
> experimenting, is very good - particularly in a document which will be
> tested at most rather indirectly.
> 
> > > > > +The process ID of the device model associated with this domain, if it
> > > > > +has one.
> > > > > +
> > > > > +XXX why is this visible to the guest?
> > > 
> > > I think some of these things were put here just because there wasn't
> > > another place for the toolstack to store things.  See also the
> > > arbitrary junk stored by scripts in the device backend directories.
> > 
> > Should we define a proper home for these? e.g. /$toolstack/$domid?
> 
> Yes, we should, but the purpose of the doc is to document what we do
> now, not what we will do :-).  I just replied to explain your XXX.

Thanks. I've tagged this one as INTERNAL.

> > > This should have a cross-reference to the documentation defining
> > > static-max etc.  I thought we had some in tree but I can't seem to
> > > find it.  The best I can find is docs/man/xl.cfg.pod.5.
> > 
> > I think you might be thinking of tools/libxl/libxl_memory.txt.
> > 
> > Shall we move that doc to docs/misc?
> 
> Good idea.

I'll incorporate this move into the next version of the patch.

> > Perhaps:
> > 
> >         every effort to ... reach this target
> > 
> > ? but I'm not sure that is strictly correct, a guest can use less if it
> > wants to. So perhaps
> > 
> >         every effort to ... not use more than this
> >         
> > ? seems clumsy though.
> 
> :-).  These all seem fine to me.

I went with "make every effort to every effort use no more
than this amount of RAM". I don't think there's any point in requiring a
guest to use more RAM than it wants to.

> > > I think it's not specified anywhere.  It's ad-hoc.  The guest
> > > shouldn't need to see it but exposing it readonly is probably
> > > harmless.  Except perhaps for the vnc password ?
> > 
> > vnc password appears to go into /vm/$uuid/vncpass (looking at libxl code
> > only).
> 
> Yuk.  We want to abolish /vm/$uuid/ surely.
> 
> > AFAIK it does nothing special with the perms, but /vm/$uuid is not guest
> > readable (perms are "n0") so I think that works out ok.
> > 
> > I wonder if that's part of the point of /vm/$uuid.
> 
> Perhaps we should make a new directory for this.  We do seem to have
> quite a bit of cruft in our system which attempting to write this
> document is revealing.
> 
> The right answer is probably to mention it in the doc as "likely to
> move".

I've noticed that nothing in here appears to be readable by guests.
Therefore I have marked them all with new tags INTERNAL (guest
should/must not read)  and "n" (guest's can't even read).

Thanks for the review/discussion. V2 of this patch to follow shortly.

Ian.



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