On 06/08/2010 03:59 PM, Luiz Capitulino wrote:
Now, QError.
This is something I think we should fix for 0.13. However, I still don't
know how to get it right: most of what you say in the wiki page has already
been discussed before.
For example, you suggest the error object should be returned, this is
probably a requirement to have async commands working, but this thread
explains the problems we had with that:
http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00818.html
Sometimes we have to make difficult changes and touch a lot of code.
There's really no other way and we're just going to have to grit our
teeth and do it. Honestly, it's not that bad though having gone through
much of the code at this point.
Another issue is that QErrors are getting too specific. I see two problems
here, first how errors should be done and how to map errno properly, also
already discussed:
http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00314.html
We're going to have to basically drop most of the QErrors we have today
for 0.14 after we straighten out the error mess.
Errors are pretty easy to deprecate and replace. All clients have to
handle new types of errors so the worst thing that will happen is that
they have less specific errors.
The big problem is things like the block io error events. I don't see
how we can support that given what we have in 0.13. Putting errno on
the wire is a bad idea. We need to marshal a QError object using the
__class__ memory to identify it as QError and pass that with the event.
It could potentially be made to work for 0.13 but it'll be ugly.
Finally, sometimes handler A and handler B can share the error class but not
the error context. I can't locate a good example right now, but this becomes
evident if you have a 1:1 mapping between QError and errno (eg, EINVAL can be
anything), so it's hard to share errors in this case and we end up creating
new ones.
But handler A and handler B have the context that they are A and B so
they can display the error differently. That's the whole point.
There should be a 1:1 mapping between QError and errno. That's the
problem with QErrors today. Instead of ENOENT, we have BusNotFound,
CommandNotFound, DeviceNotFound, FdNotFound, PropertyNotFound, and
PropertyValueNotFound.
All we really need is a single ItemNotFound event that takes a 'context'
and 'item' data. A generic way to dump the error would be '%(context)
named "%(item)" not found". The advantage of QErrors over errno is that
we can add a little bit more data to it to make error inspection a bit
friendlier. But regardless of that extra info, we should still be using
the equivalent of just ENOENT, not EBUSNOENT, ECOMMANDNOENT,
EDEVICENOENT, etc.
If you want to display more custom text, then you have to be able to
inspect the QError object, get the info from it, and then decide based
on the context the error was generated, how to display it. The ability
to work with QErrors in a meaningful way in handlers is keeping us from
doing this today.
Regards,
Anthony Liguori
