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