All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] Ignoring errno makes QMP errors suck
Date: Mon, 26 Mar 2012 10:28:14 -0300	[thread overview]
Message-ID: <20120326102814.20e2cb87@doriath.home> (raw)
In-Reply-To: <4F706B80.9080402@redhat.com>

On Mon, 26 Mar 2012 15:13:36 +0200
Kevin Wolf <kwolf@redhat.com> wrote:

> Am 26.03.2012 14:46, schrieb Luiz Capitulino:
> > On Mon, 26 Mar 2012 10:39:50 +0200
> > Kevin Wolf <kwolf@redhat.com> wrote:
> > 
> >> Hi,
> >>
> >> I keep getting reports of problems, with nice error descriptions that
> >> usually look very similar to what I produced here:
> >>
> >> {"execute":"blockdev-snapshot-sync","arguments":{"device":"ide0-hd0","snapshot-file":"/tmp/backing.qcow2"}}
> >> {"error": {"class": "OpenFileFailed", "desc": "Could not open
> >> '/tmp/backing.qcow2'", "data": {"filename": "/tmp/backing.qcow2"}}}
> >>
> >> Who can tell me what has happened here? Oh, yes, the command failed, I
> >> would have guessed that from the "error" key. But the actual error
> >> description is as useless as it gets. It doesn't tell me anything about
> >> _why_ the snapshot couldn't be created. ("Permission denied" would have
> >> been the helpful additional information in this case)
> > 
> > There's a function called qemu_fopen_err() in the screendump conversion series
> > that return more specific errors. It will be trivial to add qemu_open_err()
> > as soon as qemu_fopen_err() is merged.
> > 
> > We're adding a bunch of more precise errors (some map directly to errno). That's
> > the easy part. The hard part is to convert everything to use them.
> > 
> > Note that while it's true that this shouldn't have leaked to QMP, good error
> > reporting is a general problem in QEMU.
> 
> I guess my point is that we're actually moving backwards here. In HMP
> things like this do print the right error message (using error_report).
> And the return code is passed all the way down to where the QMP error is
> generated, it's just ignored there.
> 
> The last time I checked there was no easy way to handle it there because
> errno and strerror(-errno) aren't things allowed in QMP messages. This
> is the problem for which I wanted to get some attention.

What we're doing now is to add QErrors that map to errno. So, for example,
we have PermissionDenied for EPERM.

I think this is exactly the same thing, except:

 1. We don't use the errno number, because this may differ among OSs
 2. We don't use the sterrror() string to allow for internationalization,
    but we have our own string that should have the same end result

> Does the patch that you mentioned add a generic way for adding an
> (converted) errno to QMP errors? Or does it split up existing errors
> into more and finer grained errors?

The latter. The QMP errors have to be added manually. But it's just a matter
of time to get the most used errnos added.

  reply	other threads:[~2012-03-26 13:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-26  8:39 [Qemu-devel] Ignoring errno makes QMP errors suck Kevin Wolf
2012-03-26 12:46 ` Luiz Capitulino
2012-03-26 13:13   ` Kevin Wolf
2012-03-26 13:28     ` Luiz Capitulino [this message]
2012-03-26 13:39       ` Anthony Liguori
2012-03-26 14:04       ` Kevin Wolf
2012-03-26 14:33         ` Luiz Capitulino
2012-03-26 14:47           ` Kevin Wolf
2012-03-26 14:54             ` Luiz Capitulino
2012-03-26 15:20               ` Kevin Wolf
2012-03-26 13:37 ` Anthony Liguori
2012-03-26 15:08   ` Kevin Wolf
2012-03-26 15:14     ` Anthony Liguori
2012-03-26 15:34       ` Kevin Wolf
2012-03-26 15:38         ` Anthony Liguori
2012-03-26 15:59           ` Kevin Wolf
2012-03-26 16:01             ` Anthony Liguori

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=20120326102814.20e2cb87@doriath.home \
    --to=lcapitulino@redhat.com \
    --cc=Qemu-devel@nongnu.org \
    --cc=anthony@codemonkey.ws \
    --cc=kwolf@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.