Re: [Qemu-devel] Re: KVM call minutes for June 8

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

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux