All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Luiz Capitulino <lcapitulino@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 16:47:51 +0200	[thread overview]
Message-ID: <4F708197.10802@redhat.com> (raw)
In-Reply-To: <20120326113312.145235e6@doriath.home>

Am 26.03.2012 16:33, schrieb Luiz Capitulino:
> On Mon, 26 Mar 2012 16:04:26 +0200
> Kevin Wolf <kwolf@redhat.com> wrote:
> 
>>>> 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.
>>
>> Your PermissionDenied example doesn't really do this. It is a generic
>> error message that may occur in multiple contexts, right? So in one
>> context you may need a file name as additional information, in another
>> context permission for something completely different may be missing
>> (especially if you include EPERM in the same error).
> 
> Yes, but it's not a severe problem. Not yet. Because most of the time the
> error context can be inferred from the command's context. Say, you fail to
> create a file where only one file could be created.

So how do you like the 'transaction' command? :-)

But even if you could infer the context, the possible error details may
still differ in the possible contexts. With -blockdev this will become
even more fun, because even for bdrv_open you may or may not have a
filename. Maybe you rather have a hostname, port and sheepdog volume ID.
Or directory name, FAT type and stuff.

> But yes, we need to add a way for errors to accept optional parameters.
> 
> I have a series that's almost done that moves all errors to a qapi-error.json
> file and auto-generates the QErrors tables. Maybe that's a first step towards
> more flexible errors.
> 
>> I think 'OpenFileFailed' is not too bad, it's just missing a field that
>> gives the detail 'PermissionDenied'. I'm not sure if having
>> 'PermissionDenied' as the top-level error object is the best idea.
> 
> I think the end result is the same, but I prefer PermissionDenied as the
> top level because it's slightly simpler.

How would you do the conversion in a compatible way?

Kevin

  reply	other threads:[~2012-03-26 14:44 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
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 [this message]
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=4F708197.10802@redhat.com \
    --to=kwolf@redhat.com \
    --cc=Qemu-devel@nongnu.org \
    --cc=anthony@codemonkey.ws \
    --cc=lcapitulino@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.