All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Corey Minyard <cminyard@mvista.com>
Cc: bcketchum@gmail.com, Weidong Huang <hwd@huawei.com>,
	qemu-devel@nongnu.org, minyard@acm.org, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH 2/7] qemu-char: Allow a chardev to reconnect if disconnected
Date: Thu, 6 Mar 2014 19:41:10 +0200	[thread overview]
Message-ID: <20140306174110.GB7536@redhat.com> (raw)
In-Reply-To: <5318ADC8.1060708@mvista.com>

On Thu, Mar 06, 2014 at 11:18:00AM -0600, Corey Minyard wrote:
> On 03/06/2014 12:47 AM, Weidong Huang wrote:
> >  escape sequences.
> >  
> > +@option{reconnect} specifies that if the client socket does not connect at
> > +startup, or if the client socket is closed for some reason (like the other
> > +end exited), wait the given number of seconds and attempt to reconnect.
> > +
> >  TCP and unix socket options are given below:
> >  
> >  @table @option
> > The client will reconnect for ever when the server is dead. Is it better that try to reconnect several times?
> > Or add a option which specifies times of reconnect?
> >
> I'm not really sure about this.  For a remote IPMI BMC, you would want
> it to reconnect for forever, there's no point it having it stop trying
> after a while, since you want it to come back even if the BMC is down
> for a day.  I would think the same if you wanted a remote console or
> something of that nature.
> 
> What's the use case where you would want it to stop trying?  I can't
> think of any.
> 
> Thanks,
> 
> -corey

Depends on what happens after it fails.
Imagine whoever was using the socket is gone.
It might be useful to stop VM or exit
after a while rather than just hang about.

-- 
MST

  reply	other threads:[~2014-03-06 17:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05  0:38 [Qemu-devel] [PATCH 0/7] Allow a client chardev to reconnect if disconnected minyard
2014-03-05  0:38 ` [Qemu-devel] [PATCH 1/7] qemu-char: Allocate CharDriverState in qemu_chr_new_from_opts minyard
2014-03-05  0:38 ` [Qemu-devel] [PATCH 2/7] qemu-char: Allow a chardev to reconnect if disconnected minyard
2014-03-06  6:47   ` Weidong Huang
2014-03-06 17:18     ` Corey Minyard
2014-03-06 17:41       ` Michael S. Tsirkin [this message]
2014-03-06  7:43   ` Michael S. Tsirkin
2014-03-06 18:04     ` Corey Minyard
2014-03-06 18:43       ` Michael S. Tsirkin
2014-03-05  0:38 ` [Qemu-devel] [PATCH 3/7] qemu-char: Wait until socket connect to report connected minyard
2014-03-05  0:38 ` [Qemu-devel] [PATCH 4/7] qemu-char: remove free of chr from win_stdio_close minyard
2014-03-05  0:38 ` [Qemu-devel] [PATCH 5/7] qemu-char: Close fd at end of file minyard
2014-03-05  0:38 ` [Qemu-devel] [PATCH 6/7] qemu-char: Clean up error handling in qmp_chardev_add minyard
2014-03-05  0:38 ` [Qemu-devel] [PATCH 7/7] console: Don't use the console if NULL minyard

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=20140306174110.GB7536@redhat.com \
    --to=mst@redhat.com \
    --cc=afaerber@suse.de \
    --cc=bcketchum@gmail.com \
    --cc=cminyard@mvista.com \
    --cc=hwd@huawei.com \
    --cc=minyard@acm.org \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.