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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
