qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 7/9] qdev: Use QError for not found error


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 7/9] qdev: Use QError for not found error
Date: Mon, 19 Oct 2009 11:47:07 +0100
User-agent: Mutt/1.4.1i

On Mon, Oct 19, 2009 at 12:40:08PM +0200, Gerd Hoffmann wrote:
> >I think just returning error codes to the client is far too little
> >information. I don't think we need the fully normalized structure
> >that Luiz originally proposed with bus/dev addresses split out, but
> >we certainly need to include a string description giving as much
> >detail as possible.  If attaching a host USB device failed, I don't
> >want a single error code  QERR_OPEN_FAILED, nor a generic message
> >like 'could not open device', i want the exact details, eg
> >
> >   'could not open device: permission denied'
> >   'could not open device: no such file or directory'
> >   'could not open device: device or resource busy'
> 
> Which makes me wonder whenever it makes sense to re-use errno for the 
> error codes instead of inventing our own QERR_* codes?  Not the numbers 
> of course because they are not standardized as far I know, but the Ename 
> strings.
> 
> If you error out because a system call failed you can pass up errno 
> straight to the client without loosing information along the way.  And 
> for other error conditions it should be possible to find error codes 
> describing what happened, i.e. when trying to add a device where no 
> backend driver exists in qemu you can return ENOENT (plus freeform text 
> message for error logging).

If applicable to the context, I think it is worthwhile including more than
just the generic errno string. eg, if failed opening a disk file, then it
would be fine to just send back the errno string, because the original
drive_add command would already include the filename in question. If
failed opening some random sysfs file relating to a PCI device that is
being attached, then QEMU should back the sysfs filename because it may
not be obvious from just the PCI bus/domain/slot number in the original
command just which file QEMU failed to open.


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




reply via email to

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