All of lore.kernel.org
 help / color / mirror / Atom feed
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:28:20 +0200	[thread overview]
Message-ID: <20100110142820.GN4905@redhat.com> (raw)
In-Reply-To: <4B49C1D3.1070308@redhat.com>

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?

> This process ensures that important details are not lost: the
> morphing step attempts to preserve all the nuances, and it is much
> easier to spot a behaviour change in a review than to spot a missing
> behaviour in a new feature.  This was successfully used to merge
> i386 and x86_64 arch support in Linux.
> 
> Some qemu-kvm.git features (primarily support for very old kernels)
> can be dropped, simplifying the convergence process.
> 
> Over time, qemu-kvm.git master will converge with qemu.git master
> and all that will remain is the patch queue.
> 
> Features in qemu-kvm.git not present in qemu.git include:
> - smp support
> - in-kernel irqchip
> - in-kernel pit
> - tpr patching
> - device assignment
> - kvm paravirtualization
> - boot=on (extboot, or a real option rom)
> - test suite
> - ia64
> - signalfd support
> 
> Many others are implemented differently in the two trees.
> 
> The patch queue will appear as a branch 'uq/master' (for 'upstream
> queue); if necessary branches for the stable series will also be
> created.
> 
> 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?

> - once that's merged, post a patch series against
> qemu-kvm.git/uq/master that brings the same code into qemu.git.
> 
> The new branch will be subject to the same automatic testing that
> qemu-kvm.git is.
> 
> Please post patches to both qemu-devel and kvm mailing lists.
> 
> This won't work for all features, so we'll have to feel our way and
> make decisions on a case by case basis.
> 
> 

--
			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:28:20 +0200	[thread overview]
Message-ID: <20100110142820.GN4905@redhat.com> (raw)
In-Reply-To: <4B49C1D3.1070308@redhat.com>

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?

> This process ensures that important details are not lost: the
> morphing step attempts to preserve all the nuances, and it is much
> easier to spot a behaviour change in a review than to spot a missing
> behaviour in a new feature.  This was successfully used to merge
> i386 and x86_64 arch support in Linux.
> 
> Some qemu-kvm.git features (primarily support for very old kernels)
> can be dropped, simplifying the convergence process.
> 
> Over time, qemu-kvm.git master will converge with qemu.git master
> and all that will remain is the patch queue.
> 
> Features in qemu-kvm.git not present in qemu.git include:
> - smp support
> - in-kernel irqchip
> - in-kernel pit
> - tpr patching
> - device assignment
> - kvm paravirtualization
> - boot=on (extboot, or a real option rom)
> - test suite
> - ia64
> - signalfd support
> 
> Many others are implemented differently in the two trees.
> 
> The patch queue will appear as a branch 'uq/master' (for 'upstream
> queue); if necessary branches for the stable series will also be
> created.
> 
> 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?

> - once that's merged, post a patch series against
> qemu-kvm.git/uq/master that brings the same code into qemu.git.
> 
> The new branch will be subject to the same automatic testing that
> qemu-kvm.git is.
> 
> Please post patches to both qemu-devel and kvm mailing lists.
> 
> This won't work for all features, so we'll have to feel our way and
> make decisions on a case by case basis.
> 
> 

--
			Gleb.

  reply	other threads:[~2010-01-10 14:28 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 [this message]
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
2010-01-10 14:49       ` [Qemu-devel] " 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=20100110142820.GN4905@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.