On 06/08/2010 03:59 PM, Luiz Capitulino wrote:
quoted text
>   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.

quoted text
>   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.

quoted text
>   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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html