qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Chris Wright <chrisw@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org, armbru@redhat.com
Subject: Re: [Qemu-devel] Re: KVM call minutes for June 8
Date: Wed, 9 Jun 2010 12:18:20 -0300	[thread overview]
Message-ID: <20100609121820.1f3bb47a@redhat.com> (raw)
In-Reply-To: <4C0EB281.80907@codemonkey.ws>

On Tue, 08 Jun 2010 16:13:37 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

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

 Let's see, we should start working on this as soon as 0.13 is out.

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

 Another problem is that a client might be waiting for a specific error
that would never arrive. For example, say you wrote a shell and the
CommandNotFound error is something expected to happen, this will break.

 Yes, well written clients should check the 'error' key first and won't
panic if what they expect is not there. Even then, it's an annoying
issue.

 What we can do to minimize the damage is:

 1. Clearly state somewhere that errors are going to be removed
 2. Keep errors undocumented (this turned out to be a feature!)

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

 Yes, that's the main problem of the whole thing I think.

 From QEMU pov, the best thing to do would be to let this event as it's
today and wait for the new QError (it's a compatible change, anyway).

 However, libvirt was counting on this feature and on the snapshot commands
to switch from the text Monitor. We have two options:

 1. Ask them to wait one more release (not so good for us)
 2. Try to find a way to have those features in for 0.13

 Daniel has commented to me that making the snapshot commands synchronous
for 0.13 wouldn't be that bad, what do you think?

  reply	other threads:[~2010-06-09 15:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-08 15:05 [Qemu-devel] KVM call minutes for June 8 Chris Wright
2010-06-08 16:01 ` [Qemu-devel] " Anthony Liguori
2010-06-08 20:59   ` Luiz Capitulino
2010-06-08 21:13     ` Anthony Liguori
2010-06-09 15:18       ` Luiz Capitulino [this message]
2010-06-09 15:31         ` Daniel P. Berrange
2010-06-09 16:22           ` Anthony Liguori
2010-06-09 16:29             ` Daniel P. Berrange
2010-06-10  9:43             ` Kevin Wolf
2010-06-10 12:53               ` Anthony Liguori
2010-06-10 13:08                 ` Kevin Wolf
2010-06-10 14:11                   ` Avi Kivity
2010-06-10 14:22                     ` Kevin Wolf
2010-06-10 14:27                   ` Anthony Liguori
2010-06-11 12:55                     ` Luiz Capitulino
2010-06-11 13:48                       ` Anthony Liguori
2010-06-09 16:26         ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100609121820.1f3bb47a@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --cc=chrisw@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).