All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC 0/3] dataplane: dataplane: more graceful error handling
Date: Thu, 7 Aug 2014 17:31:11 +0200	[thread overview]
Message-ID: <20140807173111.37d4f643.cornelia.huck@de.ibm.com> (raw)
In-Reply-To: <20140807143901.GF3374@noname.redhat.com>

On Thu, 7 Aug 2014 16:39:01 +0200
Kevin Wolf <kwolf@redhat.com> wrote:

> Am 25.07.2014 um 14:10 hat Cornelia Huck geschrieben:
> > Currently, qemu will take a hard exit if it fails to set up guest or
> > host notifiers, giving no real clue as to what went wrong (e.g., when
> > out of file descriptors).
> > 
> > This patchset tries to make this more manageable: Both by improving the
> > error message and by gracefully falling back to non-dataplane in case of
> > errors.
> > 
> > Patches are also available on
> > 
> > git://github.com/cohuck/qemu dataplane-graceful-fail
> > 
> > Thoughts?
> 
> I think Stefan should comment on this, but I certainly welcome every
> patch that fixes an exit(1) call.
> 
> I'm not entirely sure about the added fprintf(). It feels wrong, but of
> course it's a lot less wrong than exiting. 

Well, I was only enhancing an existing message :) At least the admin
has a chance to find out now what went wrong.

> Ideally already adding the
> device with dataplane enabled would fail so that we can return a proper
> QMP error message instead of just dumping something on stderr. Not sure
> if it's possible, though, I don't really know that code.

The problem is that we won't fail until after we actually try to start
dataplane (i.e. when the guest is trying to use the device). Depending
on the guest, this may be when the guest has already been running for a
time (e.g. when the guest disables using some devices and the guest
admin enables them manually later).

> 
> Nothing to stop this series anyway.
> 
> Kevin
> 

  reply	other threads:[~2014-08-07 15:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-25 12:10 [Qemu-devel] [PATCH RFC 0/3] dataplane: dataplane: more graceful error handling Cornelia Huck
2014-07-25 12:10 ` [Qemu-devel] [PATCH RFC 1/3] dataplane: print why starting failed Cornelia Huck
2014-07-25 12:10 ` [Qemu-devel] [PATCH RFC 2/3] dataplane: fail notifier setting gracefully Cornelia Huck
2014-07-25 12:10 ` [Qemu-devel] [PATCH RFC 3/3] dataplane: stop trying on notifier error Cornelia Huck
2014-08-04 10:26 ` [Qemu-devel] [PATCH RFC 0/3] dataplane: dataplane: more graceful error handling Cornelia Huck
2014-08-07 14:39 ` Kevin Wolf
2014-08-07 15:31   ` Cornelia Huck [this message]
2014-08-12 12:51 ` Stefan Hajnoczi

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=20140807173111.37d4f643.cornelia.huck@de.ibm.com \
    --to=cornelia.huck@de.ibm.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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.