From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33476 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OM67J-0007rs-RP for qemu-devel@nongnu.org; Tue, 08 Jun 2010 17:13:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OM67G-0004hT-Rx for qemu-devel@nongnu.org; Tue, 08 Jun 2010 17:13:47 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:35248) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OM67G-0004hO-Og for qemu-devel@nongnu.org; Tue, 08 Jun 2010 17:13:46 -0400 Received: by iwn10 with SMTP id 10so1001000iwn.4 for ; Tue, 08 Jun 2010 14:13:45 -0700 (PDT) Message-ID: <4C0EB281.80907@codemonkey.ws> Date: Tue, 08 Jun 2010 16:13:37 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KVM call minutes for June 8 References: <20100608150500.GA28492@x200.localdomain> <4C0E694F.8040607@codemonkey.ws> <20100608175952.5f43ea8f@redhat.com> In-Reply-To: <20100608175952.5f43ea8f@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org, armbru@redhat.com 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