xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
	"Jan Rękorajski" <baggins@pld-linux.org>,
	"Ian Jackson" <ian.jackson@eu.citrix.com>,
	"Jacek Konieczny" <jajcus@jajcus.net>,
	"M A Young" <m.a.young@durham.ac.uk>,
	xen-devel@lists.xenproject.org,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Subject: Re: [PATCH v2 1/7] xenstore-read: add support for a	retry open limit on xenstored
Date: Sat, 22 Mar 2014 02:33:50 +0100	[thread overview]
Message-ID: <20140322013350.GB5011@wotan.suse.de> (raw)
In-Reply-To: <1395415270.19839.144.camel@kazak.uk.xensource.com>

On Fri, Mar 21, 2014 at 03:21:10PM +0000, Ian Campbell wrote:
> On Wed, 2014-03-19 at 13:58 -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > This adds support for a customizable retry limit on trying to open
> > the xenstored, each retry is separated by 1 second. This should allow
> > us to simplify both our LSB init scripts and eventually our systemd
> > service files for starting the xenstored.
> > 
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Jan Rękorajski <baggins@pld-linux.org>
> > Cc: M A Young <m.a.young@durham.ac.uk>
> > Cc: Jacek Konieczny <jajcus@jajcus.net>
> > Cc: xen-devel@lists.xenproject.org
> > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> > ---
> >  tools/xenstore/xenstore_client.c | 31 +++++++++++++++++++++++++------
> 
> Please update docs/man/xenstore* too.

docs/man/xenstore.pod.1 has no documentation yet on any arguments passed.
I can't see why this would be a requirement for -l if none of the others
are documented yet. Documenting only one argument would likely be pretty
confusing.

> > @@ -535,10 +536,11 @@ main(int argc, char **argv)
> >  	    {"upto",    0, 0, 'u'}, /* MODE_chmod */
> >  	    {"recurse", 0, 0, 'r'}, /* MODE_chmod */
> >  	    {"number",  1, 0, 'n'}, /* MODE_watch */
> > +	    {"limit",   1, 0, 'l'}, /* MODE_read */
> 
> Limit is an odd name for this options, --retries seems more plausible.

--retries is perfect but the --recurse option takes on the -r smaller version
flag so I went with that. Let me know how you'd like to proceed. I'd prefer
to call it --socket-retries as that would remove ambiguation from ioctl()
open retries or transaaction retries, etc, but again, s is taken for socket
only mode.

> Since this only impacts the xc_open, is there any reason to limit it to
> read? I might want to retry on any of the operations.

Technically no, we need to open the socket for any other mode of operation.

> >  	    {0, 0, 0, 0}
> >  	};
> >  
> > -	c = getopt_long(argc - switch_argv, argv + switch_argv, "hfspturn:",
> > +	c = getopt_long(argc - switch_argv, argv + switch_argv, "hfspturn:l:",
> >  			long_options, &index);
> >  	if (c == -1)
> >  	    break;
> > @@ -589,6 +591,16 @@ main(int argc, char **argv)
> >  	    else
> >  		usage(mode, switch_argv, argv[0]);
> >  	    break;
> > +	case 'l':
> > +	    if (mode == MODE_read)
> > +		limit = atoi(optarg);
> > +	    else
> > +		usage(mode, switch_argv, argv[0]);
> > +	    if (limit < 0) {
> > +		limit = 1;
> 
> Pointless?

No, limit is an int, so it can be negative. That implies nr_watches
could be negative as it didn't have this check, I can add that if you like
as part of my series. Fortunately I see no issues with a negative
nr_watches though as in the loop that its used it will always be less
than 0, so a fix technically wouldn't do anything, but it would be correct
to add it.

> > +		usage(mode, switch_argv, argv[0]);
> > +	    }
> > +	    break;
> >  	}
> >      }
> >  
> > @@ -632,8 +644,15 @@ main(int argc, char **argv)
> >  	    max_width = ws.ws_col - 2;
> >      }
> >  
> > -    xsh = xs_open(socket ? XS_OPEN_SOCKETONLY : 0);
> 
> It occurs to me that retrying might be incompatible with the ring base
> (i.e. non-socket) method of talking to xenstored. Harmless to retry
> though  I suppose.

How so, I mean, if it can only succeed or not, and if it didn't I don't
see how retrying to open the same path would be incompatible?

> > -    if (xsh == NULL) err(1, "xs_open");
> > +    for (open_tries = 0; open_tries < limit; open_tries++) {
> 
> "while(limit--)" (well, retries--)

Yeah that saves us an int.

>  and the adjustments inside the loop
> which this implies would be more natural I think.

Which adjustment? If you mean the branch check on if (limit > 1) -- that
is still needed otherwise we sleep(1) even if it worked.

> > +	    xsh = xs_open(socket ? XS_OPEN_SOCKETONLY : 0);
> > +	    if (xsh)
> > +		    break;
> > +	    if (limit > 1)
> > +		    sleep(1);
> > +    }
> > +    if (!xsh)
> > +	    err(1, "xs_open");
> >  
> >  again:
> >      if (transaction) {
> 
> 
> 

  Luis

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

  parent reply	other threads:[~2014-03-22  1:34 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19 20:58 [PATCH v2 0/7] xen: add systemd files Luis R. Rodriguez
2014-03-19 20:58 ` [PATCH v2 1/7] xenstore-read: add support for a retry open limit on xenstored Luis R. Rodriguez
2014-03-21 15:21   ` Ian Campbell
2014-03-21 15:22     ` Ian Jackson
2014-03-22  1:36       ` Luis R. Rodriguez
2014-03-22  1:33     ` Luis R. Rodriguez [this message]
2014-03-24  9:57       ` Ian Campbell
2014-03-21 15:40   ` David Vrabel
2014-03-21 16:01     ` Ian Campbell
2014-03-22  1:43       ` Luis R. Rodriguez
2014-03-24 10:01         ` Ian Campbell
2014-03-22  1:41     ` Luis R. Rodriguez
2014-03-19 20:58 ` [PATCH v2 2/7] xencommons: use the retry limit instead of implementing our own timeout Luis R. Rodriguez
2014-03-21 15:24   ` Ian Campbell
2014-03-19 20:58 ` [PATCH v2 3/7] tools/xendomains: make xl the default Luis R. Rodriguez
2014-03-21 15:26   ` Ian Campbell
2014-03-19 20:58 ` [PATCH v2 4/7] tools/xendomains: remove old redhat check Luis R. Rodriguez
2014-03-21 15:28   ` Ian Campbell
2014-03-22  1:56     ` Luis R. Rodriguez
2014-03-19 20:58 ` [PATCH v2 5/7] tools/xendomains: do space cleanups Luis R. Rodriguez
2014-03-21 15:29   ` Ian Campbell
2014-03-19 20:58 ` [PATCH v2 6/7] tools/xendomains: move to sbin and use init helper Luis R. Rodriguez
2014-03-19 22:03   ` Olaf Hering
2014-03-22  2:00     ` Luis R. Rodriguez
2014-03-21 15:34   ` Ian Campbell
2014-03-22  2:17     ` Luis R. Rodriguez
2014-03-24 10:09       ` Ian Campbell
2014-04-28  5:11         ` Luis R. Rodriguez
2014-04-28  9:15           ` Ian Campbell
2014-04-28 10:47             ` Luis R. Rodriguez
2014-03-19 20:58 ` [PATCH v2 7/7] systemd: add support initial xen systemd service files Luis R. Rodriguez
2014-03-19 21:05   ` Luis R. Rodriguez
2014-03-21 10:08   ` Ian Campbell
2014-03-22  2:26     ` Luis R. Rodriguez
2014-03-24 10:11       ` Ian Campbell
2014-03-24 16:36         ` Luis R. Rodriguez
2014-04-28  5:12         ` Luis R. Rodriguez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140322013350.GB5011@wotan.suse.de \
    --to=mcgrof@suse.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=baggins@pld-linux.org \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jajcus@jajcus.net \
    --cc=m.a.young@durham.ac.uk \
    --cc=mcgrof@do-not-panic.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).