From: Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, KVM list <kvm@vger.kernel.org>
Subject: Re: New kvm-related qemu patch queue
Date: Sun, 10 Jan 2010 16:49:04 +0200 [thread overview]
Message-ID: <20100110144904.GO4905@redhat.com> (raw)
In-Reply-To: <4B49E494.3030400@redhat.com>
On Sun, Jan 10, 2010 at 04:30:44PM +0200, Avi Kivity wrote:
> On 01/10/2010 04:28 PM, Gleb Natapov wrote:
> >On Sun, Jan 10, 2010 at 02:02:27PM +0200, Avi Kivity wrote:
> >>In order to improve qemu.git kvm integration quality wrt
> >>performance, features, and reliability Marcelo and I will begin to
> >>maintain a patch queue based on qemu.git containing kvm-related
> >>patches. We will review and apply patches to this queue, test them
> >>using the same test suite that is used for qemu-kvm.git, and
> >>regularly submit them for inclusion in qemu.git, mimicking the
> >>relationship between kvm.git and Linus' linux-2.6.git.
> >>
> >>One of the problems of qemu.git kvm support is that it is a clean
> >>reimplementation, and thus some of the nuances that were carefully
> >>ironed out in qemu-kvm.git are lost. To that end, we would like to
> >>change the process of adding features as follows:
> >>
> >> - first, the feature in qemu-kvm.git master is morphed to a form
> >>suitable for merging into qemu.git
> >> - when that has been accomplished, the feature is broken into
> >>patches and merged into the patch queue
> >>
> >If there is the same feature in qemu-kvm.git and qemu.git whom is morphed to
> >whom and who is merged where? I am confused. We have much of duplicated
> >code between qemu-kvm.git and qemu.git it is often almost, but not exactly the
> >same. Is it really productive to set rules who should be morphed and how
> >at this point?
>
> If the feature is already in both, then morph qemu-kvm.git into what
> is already in qemu.git. Hopefully anything missing in qemu.git will
> be discovered while making the changes.
>
What about bugs that are present only in qemu.git? Like this:
http://patchwork.ozlabs.org/patch/42298/. Should it go through
qemu-kvm.git/uq/master?
What about this one: http://patchwork.ozlabs.org/patch/42447/ should it
be postponed untill qemu.git and qemu-kvm.git converge on using the same
cpuid infrastructure, or add similar functionality to qemu-kvm to,
or add new cpu flags to qemu-kvm only and when cpuid code converge
qemu.git will have it too?
> >>In order to get a kvm feature into qemu.git, please observe the
> >>following process:
> >>
> >>- post a patch series against qemu-kvm.git/master that implements
> >>the feature, or changes an existing feature to use qemu.git
> >>infrastructure
> >It was other way around till last week. Why change?
>
> There were a lot of regressions.
>
Yeah :(
--
Gleb.
WARNING: multiple messages have this Message-ID (diff)
From: Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, KVM list <kvm@vger.kernel.org>
Subject: [Qemu-devel] Re: New kvm-related qemu patch queue
Date: Sun, 10 Jan 2010 16:49:04 +0200 [thread overview]
Message-ID: <20100110144904.GO4905@redhat.com> (raw)
In-Reply-To: <4B49E494.3030400@redhat.com>
On Sun, Jan 10, 2010 at 04:30:44PM +0200, Avi Kivity wrote:
> On 01/10/2010 04:28 PM, Gleb Natapov wrote:
> >On Sun, Jan 10, 2010 at 02:02:27PM +0200, Avi Kivity wrote:
> >>In order to improve qemu.git kvm integration quality wrt
> >>performance, features, and reliability Marcelo and I will begin to
> >>maintain a patch queue based on qemu.git containing kvm-related
> >>patches. We will review and apply patches to this queue, test them
> >>using the same test suite that is used for qemu-kvm.git, and
> >>regularly submit them for inclusion in qemu.git, mimicking the
> >>relationship between kvm.git and Linus' linux-2.6.git.
> >>
> >>One of the problems of qemu.git kvm support is that it is a clean
> >>reimplementation, and thus some of the nuances that were carefully
> >>ironed out in qemu-kvm.git are lost. To that end, we would like to
> >>change the process of adding features as follows:
> >>
> >> - first, the feature in qemu-kvm.git master is morphed to a form
> >>suitable for merging into qemu.git
> >> - when that has been accomplished, the feature is broken into
> >>patches and merged into the patch queue
> >>
> >If there is the same feature in qemu-kvm.git and qemu.git whom is morphed to
> >whom and who is merged where? I am confused. We have much of duplicated
> >code between qemu-kvm.git and qemu.git it is often almost, but not exactly the
> >same. Is it really productive to set rules who should be morphed and how
> >at this point?
>
> If the feature is already in both, then morph qemu-kvm.git into what
> is already in qemu.git. Hopefully anything missing in qemu.git will
> be discovered while making the changes.
>
What about bugs that are present only in qemu.git? Like this:
http://patchwork.ozlabs.org/patch/42298/. Should it go through
qemu-kvm.git/uq/master?
What about this one: http://patchwork.ozlabs.org/patch/42447/ should it
be postponed untill qemu.git and qemu-kvm.git converge on using the same
cpuid infrastructure, or add similar functionality to qemu-kvm to,
or add new cpu flags to qemu-kvm only and when cpuid code converge
qemu.git will have it too?
> >>In order to get a kvm feature into qemu.git, please observe the
> >>following process:
> >>
> >>- post a patch series against qemu-kvm.git/master that implements
> >>the feature, or changes an existing feature to use qemu.git
> >>infrastructure
> >It was other way around till last week. Why change?
>
> There were a lot of regressions.
>
Yeah :(
--
Gleb.
next prev parent reply other threads:[~2010-01-10 14:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-10 12:02 New kvm-related qemu patch queue Avi Kivity
2010-01-10 12:02 ` [Qemu-devel] " Avi Kivity
2010-01-10 14:28 ` Gleb Natapov
2010-01-10 14:28 ` [Qemu-devel] " Gleb Natapov
2010-01-10 14:30 ` Avi Kivity
2010-01-10 14:30 ` [Qemu-devel] " Avi Kivity
2010-01-10 14:49 ` Gleb Natapov [this message]
2010-01-10 14:49 ` Gleb Natapov
2010-01-10 14:52 ` Avi Kivity
2010-01-10 14:52 ` [Qemu-devel] " Avi Kivity
2010-01-11 7:51 ` Gleb Natapov
2010-01-11 7:51 ` [Qemu-devel] " Gleb Natapov
2010-01-11 15:30 ` Anthony Liguori
2010-01-11 15:30 ` [Qemu-devel] " Anthony Liguori
2010-01-17 12:51 ` Avi Kivity
2010-01-17 12:51 ` [Qemu-devel] " Avi Kivity
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=20100110144904.GO4905@redhat.com \
--to=gleb@redhat.com \
--cc=avi@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.