qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Ignoring errno makes QMP errors suck


From: Kevin Wolf
Subject: Re: [Qemu-devel] Ignoring errno makes QMP errors suck
Date: Mon, 26 Mar 2012 16:47:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1

Am 26.03.2012 16:33, schrieb Luiz Capitulino:
> On Mon, 26 Mar 2012 16:04:26 +0200
> Kevin Wolf <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]