From: Ingo Molnar <mingo@elte.hu>
To: John Kacur <jkacur@redhat.com>
Cc: "Ted Ts'o" <tytso@mit.edu>,
"Anthony Liguori" <anthony@codemonkey.ws>,
"Pekka Enberg" <penberg@kernel.org>,
"Vince Weaver" <vince@deater.net>, "Avi Kivity" <avi@redhat.com>,
"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org List"
<linux-kernel@vger.kernel.org>,
"qemu-devel Developers" <qemu-devel@nongnu.org>,
"Alexander Graf" <agraf@suse.de>,
"Blue Swirl" <blauwirbel@gmail.com>,
"Américo Wang" <xiyou.wangcong@gmail.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
"Arnaldo Carvalho de Melo" <acme@redhat.com>
Subject: Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/
Date: Wed, 9 Nov 2011 09:38:12 +0100 [thread overview]
Message-ID: <20111109083812.GC11473@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.1111082212560.8887@localhost6.localdomain6>
* John Kacur <jkacur@redhat.com> wrote:
> On Tue, 8 Nov 2011, Ted Ts'o wrote:
>
> > On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
> > > I guess you can do well with a split project as well - my main
> > > claim is that good compatibility comes *naturally* with
> > > integration.
> >
> > Here I have to disagree; my main worry is that integration makes
> > it *naturally* easy for people to skip the hard work needed to
> > keep a stable kernel/userspace interface.
> >
> > The other worry which I've mentioned, but which I haven't seen
> > addressed, is that the even if you can use a perf from a newer
> > kernel with an older kernel, this causes distributions a huge
> > amount of pain, since they have to package two different kernel
> > source packages, and only compile perf from the newer kernel
> > source package. This leads to all sorts of confusion from a
> > distribution packaging point of view.
> >
> > For example, assume that RHEL 5, which is using 2.6.32 or
> > something like that, wants to use a newer e2fsck that does a
> > better job fixing file system corruptions. If it were bundled
> > with the kernel, then they would have to package up the v3.1
> > kernel sources, and have a source RPM that isn't used for
> > building kernel sources, but just to build a newer version of
> > e2fsck. Fortunately, they don't have to do that. They just pull
> > down a newer version of e2fsprogs, and package, build, test, and
> > ship that.
> >
> > In addition, suppose Red Hat ships a security bug fix which means
> > a new kernel-image RPM has to be shipped. Does that mean that
> > Red Hat has to ship new binary RPM's for any and all tools/*
> > programs that they have packaged as separate RPM's? Or should
> > installing a new kernel RPM also imply dropping new binaries in
> > /usr/bin/perf, et. al? There are all sorts of packaging questions
> > that are raised integration, and from where I sit I don't think
> > they've been adequately solved yet.
> >
>
> This in practice is not a big deal.
>
> There are many approaches for how the RPM can be built, but basically
> getting the perf source is just a matter of
> make perf-tar-src-pkg or friends such as
> make perf-tarbz2-src-pkg
> which will create perf-3.2.0-rc1.tar, and perf-3.2.0-rc1.tar.bz2
> respectively which can be used for the src rpms. This tar ball can be used
> as a separate package or subpackage.
Great - the 'perf is impossible for distros' was a common counter
argument early in the perf project's lifetime - i'm glad it turned
out to be bogus in practice.
Would it further simplify distro side life if all utilities deeply
related to the kernel got built together and came in a single well
working package? kutils-3.2.0-rc1.rpm or such.
They would always upgrade together with the kernel so there would
never be any forced backporting or separate errata pressure, beyond
the existing flow of -stable fixes.
We do -stable fixes for tools/perf/ as well, for stability/security
fixes, naturally - other tools would have to follow the regular
kernel maintenance process to manage high priority fixes.
Basically distros could rely on the kernel and its utilities being a
coherent whole, which is expected to work together, which is
maintained and built together and which, if it regresses, is handled
by the regular -stable kernel regressions process with high priority.
I expect it would grow one by one - it's not like we can or want to
force utilities to go into the kernel proper. I'd also expect that
new tools would be added initially - not existing ones moved. My
question to you would rather be, would it make the life of distro
release engineers gradually easier if this space grew gradually over
the years, adding more and more critical tool functionality?
Thanks,
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: John Kacur <jkacur@redhat.com>
Cc: "Alexander Graf" <agraf@suse.de>, "Ted Ts'o" <tytso@mit.edu>,
"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
"qemu-devel Developers" <qemu-devel@nongnu.org>,
"Vince Weaver" <vince@deater.net>,
"linux-kernel@vger.kernel.org List"
<linux-kernel@vger.kernel.org>,
"Pekka Enberg" <penberg@kernel.org>,
"Blue Swirl" <blauwirbel@gmail.com>,
"Arnaldo Carvalho de Melo" <acme@redhat.com>,
"Avi Kivity" <avi@redhat.com>,
"Américo Wang" <xiyou.wangcong@gmail.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/
Date: Wed, 9 Nov 2011 09:38:12 +0100 [thread overview]
Message-ID: <20111109083812.GC11473@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.1111082212560.8887@localhost6.localdomain6>
* John Kacur <jkacur@redhat.com> wrote:
> On Tue, 8 Nov 2011, Ted Ts'o wrote:
>
> > On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
> > > I guess you can do well with a split project as well - my main
> > > claim is that good compatibility comes *naturally* with
> > > integration.
> >
> > Here I have to disagree; my main worry is that integration makes
> > it *naturally* easy for people to skip the hard work needed to
> > keep a stable kernel/userspace interface.
> >
> > The other worry which I've mentioned, but which I haven't seen
> > addressed, is that the even if you can use a perf from a newer
> > kernel with an older kernel, this causes distributions a huge
> > amount of pain, since they have to package two different kernel
> > source packages, and only compile perf from the newer kernel
> > source package. This leads to all sorts of confusion from a
> > distribution packaging point of view.
> >
> > For example, assume that RHEL 5, which is using 2.6.32 or
> > something like that, wants to use a newer e2fsck that does a
> > better job fixing file system corruptions. If it were bundled
> > with the kernel, then they would have to package up the v3.1
> > kernel sources, and have a source RPM that isn't used for
> > building kernel sources, but just to build a newer version of
> > e2fsck. Fortunately, they don't have to do that. They just pull
> > down a newer version of e2fsprogs, and package, build, test, and
> > ship that.
> >
> > In addition, suppose Red Hat ships a security bug fix which means
> > a new kernel-image RPM has to be shipped. Does that mean that
> > Red Hat has to ship new binary RPM's for any and all tools/*
> > programs that they have packaged as separate RPM's? Or should
> > installing a new kernel RPM also imply dropping new binaries in
> > /usr/bin/perf, et. al? There are all sorts of packaging questions
> > that are raised integration, and from where I sit I don't think
> > they've been adequately solved yet.
> >
>
> This in practice is not a big deal.
>
> There are many approaches for how the RPM can be built, but basically
> getting the perf source is just a matter of
> make perf-tar-src-pkg or friends such as
> make perf-tarbz2-src-pkg
> which will create perf-3.2.0-rc1.tar, and perf-3.2.0-rc1.tar.bz2
> respectively which can be used for the src rpms. This tar ball can be used
> as a separate package or subpackage.
Great - the 'perf is impossible for distros' was a common counter
argument early in the perf project's lifetime - i'm glad it turned
out to be bogus in practice.
Would it further simplify distro side life if all utilities deeply
related to the kernel got built together and came in a single well
working package? kutils-3.2.0-rc1.rpm or such.
They would always upgrade together with the kernel so there would
never be any forced backporting or separate errata pressure, beyond
the existing flow of -stable fixes.
We do -stable fixes for tools/perf/ as well, for stability/security
fixes, naturally - other tools would have to follow the regular
kernel maintenance process to manage high priority fixes.
Basically distros could rely on the kernel and its utilities being a
coherent whole, which is expected to work together, which is
maintained and built together and which, if it regresses, is handled
by the regular -stable kernel regressions process with high priority.
I expect it would grow one by one - it's not like we can or want to
force utilities to go into the kernel proper. I'd also expect that
new tools would be added initially - not existing ones moved. My
question to you would rather be, would it make the life of distro
release engineers gradually easier if this space grew gradually over
the years, adding more and more critical tool functionality?
Thanks,
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: John Kacur <jkacur@redhat.com>
Cc: "Alexander Graf" <agraf@suse.de>, "Ted Ts'o" <tytso@mit.edu>,
"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
"qemu-devel Developers" <qemu-devel@nongnu.org>,
"Vince Weaver" <vince@deater.net>,
"linux-kernel@vger.kernel.org List"
<linux-kernel@vger.kernel.org>,
"Pekka Enberg" <penberg@kernel.org>,
"Blue Swirl" <blauwirbel@gmail.com>,
"Arnaldo Carvalho de Melo" <acme@redhat.com>,
"Avi Kivity" <avi@redhat.com>,
"Américo Wang" <xiyou.wangcong@gmail.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/
Date: Wed, 9 Nov 2011 09:38:12 +0100 [thread overview]
Message-ID: <20111109083812.GC11473@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.1111082212560.8887@localhost6.localdomain6>
* John Kacur <jkacur@redhat.com> wrote:
> On Tue, 8 Nov 2011, Ted Ts'o wrote:
>
> > On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
> > > I guess you can do well with a split project as well - my main
> > > claim is that good compatibility comes *naturally* with
> > > integration.
> >
> > Here I have to disagree; my main worry is that integration makes
> > it *naturally* easy for people to skip the hard work needed to
> > keep a stable kernel/userspace interface.
> >
> > The other worry which I've mentioned, but which I haven't seen
> > addressed, is that the even if you can use a perf from a newer
> > kernel with an older kernel, this causes distributions a huge
> > amount of pain, since they have to package two different kernel
> > source packages, and only compile perf from the newer kernel
> > source package. This leads to all sorts of confusion from a
> > distribution packaging point of view.
> >
> > For example, assume that RHEL 5, which is using 2.6.32 or
> > something like that, wants to use a newer e2fsck that does a
> > better job fixing file system corruptions. If it were bundled
> > with the kernel, then they would have to package up the v3.1
> > kernel sources, and have a source RPM that isn't used for
> > building kernel sources, but just to build a newer version of
> > e2fsck. Fortunately, they don't have to do that. They just pull
> > down a newer version of e2fsprogs, and package, build, test, and
> > ship that.
> >
> > In addition, suppose Red Hat ships a security bug fix which means
> > a new kernel-image RPM has to be shipped. Does that mean that
> > Red Hat has to ship new binary RPM's for any and all tools/*
> > programs that they have packaged as separate RPM's? Or should
> > installing a new kernel RPM also imply dropping new binaries in
> > /usr/bin/perf, et. al? There are all sorts of packaging questions
> > that are raised integration, and from where I sit I don't think
> > they've been adequately solved yet.
> >
>
> This in practice is not a big deal.
>
> There are many approaches for how the RPM can be built, but basically
> getting the perf source is just a matter of
> make perf-tar-src-pkg or friends such as
> make perf-tarbz2-src-pkg
> which will create perf-3.2.0-rc1.tar, and perf-3.2.0-rc1.tar.bz2
> respectively which can be used for the src rpms. This tar ball can be used
> as a separate package or subpackage.
Great - the 'perf is impossible for distros' was a common counter
argument early in the perf project's lifetime - i'm glad it turned
out to be bogus in practice.
Would it further simplify distro side life if all utilities deeply
related to the kernel got built together and came in a single well
working package? kutils-3.2.0-rc1.rpm or such.
They would always upgrade together with the kernel so there would
never be any forced backporting or separate errata pressure, beyond
the existing flow of -stable fixes.
We do -stable fixes for tools/perf/ as well, for stability/security
fixes, naturally - other tools would have to follow the regular
kernel maintenance process to manage high priority fixes.
Basically distros could rely on the kernel and its utilities being a
coherent whole, which is expected to work together, which is
maintained and built together and which, if it regresses, is handled
by the regular -stable kernel regressions process with high priority.
I expect it would grow one by one - it's not like we can or want to
force utilities to go into the kernel proper. I'd also expect that
new tools would be added initially - not existing ones moved. My
question to you would rather be, would it make the life of distro
release engineers gradually easier if this space grew gradually over
the years, adding more and more critical tool functionality?
Thanks,
Ingo
next prev parent reply other threads:[~2011-11-09 8:40 UTC|newest]
Thread overview: 421+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-06 1:35 [PATCH] KVM: Add wrapper script around QEMU to test kernels Alexander Graf
2011-11-06 1:35 ` [Qemu-devel] " Alexander Graf
2011-11-06 1:35 ` Alexander Graf
2011-11-06 1:14 ` [Qemu-devel] " Andreas Färber
2011-11-06 1:14 ` Andreas Färber
2011-11-06 10:04 ` Pekka Enberg
2011-11-06 10:04 ` [Qemu-devel] " Pekka Enberg
2011-11-06 10:04 ` Pekka Enberg
2011-11-06 10:07 ` Avi Kivity
2011-11-06 10:07 ` [Qemu-devel] " Avi Kivity
2011-11-06 10:07 ` Avi Kivity
2011-11-06 10:12 ` Pekka Enberg
2011-11-06 10:12 ` [Qemu-devel] " Pekka Enberg
2011-11-06 10:12 ` Pekka Enberg
2011-11-06 10:23 ` Avi Kivity
2011-11-06 10:23 ` [Qemu-devel] " Avi Kivity
2011-11-06 10:23 ` Avi Kivity
2011-11-06 11:08 ` Pekka Enberg
2011-11-06 11:08 ` [Qemu-devel] " Pekka Enberg
2011-11-06 11:08 ` Pekka Enberg
2011-11-06 11:50 ` Avi Kivity
2011-11-06 11:50 ` [Qemu-devel] " Avi Kivity
2011-11-06 11:50 ` Avi Kivity
2011-11-06 12:14 ` Pekka Enberg
2011-11-06 12:14 ` [Qemu-devel] " Pekka Enberg
2011-11-06 12:14 ` Pekka Enberg
2011-11-06 12:27 ` Avi Kivity
2011-11-06 12:27 ` [Qemu-devel] " Avi Kivity
2011-11-06 12:27 ` Avi Kivity
2011-11-06 12:32 ` Pekka Enberg
2011-11-06 12:32 ` [Qemu-devel] " Pekka Enberg
2011-11-06 12:32 ` Pekka Enberg
2011-11-06 12:43 ` Avi Kivity
2011-11-06 12:43 ` [Qemu-devel] " Avi Kivity
2011-11-06 12:43 ` Avi Kivity
2011-11-06 13:06 ` Pekka Enberg
2011-11-06 13:06 ` [Qemu-devel] " Pekka Enberg
2011-11-06 13:06 ` Pekka Enberg
2011-11-06 15:56 ` Avi Kivity
2011-11-06 15:56 ` [Qemu-devel] " Avi Kivity
2011-11-06 15:56 ` Avi Kivity
2011-11-06 16:35 ` Pekka Enberg
2011-11-06 16:35 ` [Qemu-devel] " Pekka Enberg
2011-11-06 16:35 ` Pekka Enberg
2011-11-06 16:50 ` Avi Kivity
2011-11-06 16:50 ` [Qemu-devel] " Avi Kivity
2011-11-06 17:08 ` Anthony Liguori
2011-11-06 17:08 ` Anthony Liguori
2011-11-06 17:08 ` Anthony Liguori
2011-11-06 18:09 ` [Qemu-devel] " Pekka Enberg
2011-11-06 18:09 ` Pekka Enberg
2011-11-06 18:09 ` Pekka Enberg
2011-11-07 1:38 ` [Qemu-devel] " Anthony Liguori
2011-11-07 1:38 ` Anthony Liguori
2011-11-07 1:38 ` Anthony Liguori
2011-11-07 6:45 ` [Qemu-devel] " Pekka Enberg
2011-11-07 6:45 ` Pekka Enberg
2011-11-06 18:31 ` Ted Ts'o
2011-11-06 18:31 ` Ted Ts'o
2011-11-06 18:54 ` Pekka Enberg
2011-11-06 18:58 ` Pekka Enberg
2011-11-06 23:19 ` Ted Ts'o
2011-11-06 23:19 ` Ted Ts'o
2011-11-07 6:42 ` Pekka Enberg
2011-11-07 6:42 ` Pekka Enberg
2011-11-07 6:42 ` Pekka Enberg
2011-11-07 17:03 ` [Qemu-devel] " Vince Weaver
2011-11-07 17:03 ` Vince Weaver
2011-11-07 17:03 ` Vince Weaver
2011-11-07 17:59 ` [Qemu-devel] " Ingo Molnar
2011-11-07 17:59 ` Ingo Molnar
2011-11-07 20:03 ` Frank Ch. Eigler
2011-11-07 20:03 ` Frank Ch. Eigler
2011-11-07 20:03 ` Frank Ch. Eigler
2011-11-07 20:09 ` [Qemu-devel] " Pekka Enberg
2011-11-07 20:09 ` Pekka Enberg
2011-11-07 20:09 ` Pekka Enberg
2011-11-07 20:35 ` [Qemu-devel] " Ted Ts'o
2011-11-07 20:35 ` Ted Ts'o
2011-11-08 10:22 ` [F.A.Q.] perf ABI backwards and forwards compatibility Ingo Molnar
2011-11-08 10:22 ` [Qemu-devel] " Ingo Molnar
2011-11-08 10:22 ` Ingo Molnar
2011-11-08 10:32 ` Peter Zijlstra
2011-11-08 10:32 ` [Qemu-devel] " Peter Zijlstra
2011-11-08 10:32 ` Peter Zijlstra
2011-11-08 11:34 ` Ingo Molnar
2011-11-08 11:34 ` [Qemu-devel] " Ingo Molnar
2011-11-08 10:41 ` Theodore Tso
2011-11-08 10:41 ` [Qemu-devel] " Theodore Tso
2011-11-08 11:20 ` Pekka Enberg
2011-11-08 11:20 ` [Qemu-devel] " Pekka Enberg
2011-11-08 11:20 ` Pekka Enberg
2011-11-08 11:25 ` Theodore Tso
2011-11-08 11:25 ` [Qemu-devel] " Theodore Tso
2011-11-08 11:25 ` Theodore Tso
2011-11-08 11:29 ` Pekka Enberg
2011-11-08 11:29 ` [Qemu-devel] " Pekka Enberg
2011-11-08 11:31 ` Frank Ch. Eigler
2011-11-08 11:31 ` [Qemu-devel] " Frank Ch. Eigler
2011-11-08 11:39 ` Pekka Enberg
2011-11-08 11:39 ` [Qemu-devel] " Pekka Enberg
2011-11-08 12:15 ` Ingo Molnar
2011-11-08 12:15 ` [Qemu-devel] " Ingo Molnar
2011-11-08 12:20 ` Peter Zijlstra
2011-11-08 12:20 ` [Qemu-devel] " Peter Zijlstra
2011-11-08 12:20 ` Peter Zijlstra
2011-11-08 12:59 ` Ingo Molnar
2011-11-08 12:59 ` [Qemu-devel] " Ingo Molnar
2011-11-09 10:05 ` Peter Zijlstra
2011-11-09 10:05 ` [Qemu-devel] " Peter Zijlstra
2011-11-09 10:05 ` Peter Zijlstra
2011-11-08 5:29 ` [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels Vince Weaver
2011-11-08 5:29 ` Vince Weaver
2011-11-08 12:07 ` Ingo Molnar
2011-11-08 12:07 ` Ingo Molnar
2011-11-08 12:07 ` Ingo Molnar
2011-11-08 13:08 ` [Qemu-devel] " Arnaldo Carvalho de Melo
2011-11-08 13:08 ` Arnaldo Carvalho de Melo
2011-11-08 13:08 ` Arnaldo Carvalho de Melo
2011-11-09 6:04 ` [Qemu-devel] " Vince Weaver
2011-11-09 6:04 ` Vince Weaver
2011-11-09 6:04 ` Vince Weaver
2011-11-07 19:53 ` [Qemu-devel] " Pekka Enberg
2011-11-07 19:53 ` Pekka Enberg
2011-11-07 20:32 ` Ted Ts'o
2011-11-07 20:32 ` Ted Ts'o
2011-11-07 20:32 ` Ted Ts'o
2011-11-07 21:36 ` [Qemu-devel] " Pekka Enberg
2011-11-07 21:36 ` Pekka Enberg
2011-11-07 22:19 ` Anthony Liguori
2011-11-07 22:19 ` Anthony Liguori
2011-11-07 22:19 ` Anthony Liguori
2011-11-07 23:42 ` [Qemu-devel] " Theodore Tso
2011-11-07 23:42 ` Theodore Tso
2011-11-07 23:42 ` Theodore Tso
2011-11-08 9:32 ` [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/ Ingo Molnar
2011-11-08 9:32 ` [Qemu-devel] " Ingo Molnar
2011-11-08 10:21 ` Theodore Tso
2011-11-08 10:21 ` [Qemu-devel] " Theodore Tso
2011-11-08 10:21 ` Theodore Tso
2011-11-08 12:55 ` Ingo Molnar
2011-11-08 12:55 ` [Qemu-devel] " Ingo Molnar
2011-11-08 12:55 ` Ingo Molnar
2011-11-08 16:33 ` Ted Ts'o
2011-11-08 16:33 ` [Qemu-devel] " Ted Ts'o
2011-11-08 17:14 ` Anca Emanuel
2011-11-08 17:14 ` Anca Emanuel
2011-11-08 17:14 ` [Qemu-devel] " Anca Emanuel
2011-11-08 19:24 ` Ted Ts'o
2011-11-08 19:24 ` [Qemu-devel] " Ted Ts'o
2011-11-09 8:28 ` Ingo Molnar
2011-11-09 8:28 ` Ingo Molnar
2011-11-09 8:28 ` [Qemu-devel] " Ingo Molnar
2011-11-08 21:15 ` John Kacur
2011-11-08 21:15 ` John Kacur
2011-11-08 21:15 ` [Qemu-devel] " John Kacur
2011-11-09 8:38 ` Ingo Molnar [this message]
2011-11-09 8:38 ` Ingo Molnar
2011-11-09 8:38 ` Ingo Molnar
2011-11-09 8:23 ` Ingo Molnar
2011-11-09 8:23 ` [Qemu-devel] " Ingo Molnar
2011-11-10 1:41 ` Alexander Graf
2011-11-10 1:41 ` [Qemu-devel] " Alexander Graf
2011-11-10 1:41 ` Alexander Graf
2011-11-10 8:14 ` Ingo Molnar
2011-11-10 8:14 ` [Qemu-devel] " Ingo Molnar
2011-11-10 8:14 ` Ingo Molnar
2011-11-09 8:23 ` Ingo Molnar
2011-11-08 12:56 ` Arnaldo Carvalho de Melo
2011-11-08 12:56 ` [Qemu-devel] " Arnaldo Carvalho de Melo
2011-11-08 13:40 ` Gerd Hoffmann
2011-11-08 13:40 ` [Qemu-devel] " Gerd Hoffmann
2011-11-08 14:32 ` Arnaldo Carvalho de Melo
2011-11-08 14:32 ` [Qemu-devel] " Arnaldo Carvalho de Melo
2011-11-08 15:38 ` Gerd Hoffmann
2011-11-08 15:38 ` [Qemu-devel] " Gerd Hoffmann
2011-11-08 16:13 ` Arnaldo Carvalho de Melo
2011-11-08 16:13 ` [Qemu-devel] " Arnaldo Carvalho de Melo
2011-11-09 8:55 ` Ingo Molnar
2011-11-09 8:55 ` [Qemu-devel] " Ingo Molnar
2011-11-09 8:55 ` Ingo Molnar
2011-11-09 8:51 ` Ingo Molnar
2011-11-09 8:51 ` [Qemu-devel] " Ingo Molnar
2011-11-09 10:40 ` Gerd Hoffmann
2011-11-09 10:40 ` [Qemu-devel] " Gerd Hoffmann
2011-11-09 10:50 ` Hagen Paul Pfeifer
2011-11-09 10:50 ` [Qemu-devel] " Hagen Paul Pfeifer
2011-11-09 11:55 ` Arnaldo Carvalho de Melo
2011-11-09 11:55 ` [Qemu-devel] " Arnaldo Carvalho de Melo
2011-11-09 11:55 ` Arnaldo Carvalho de Melo
2011-11-09 12:26 ` Gerd Hoffmann
2011-11-09 12:26 ` [Qemu-devel] " Gerd Hoffmann
2011-11-09 12:26 ` Gerd Hoffmann
2011-11-09 12:30 ` Arnaldo Carvalho de Melo
2011-11-09 12:30 ` [Qemu-devel] " Arnaldo Carvalho de Melo
2011-11-09 12:33 ` Arnaldo Carvalho de Melo
2011-11-09 12:33 ` [Qemu-devel] " Arnaldo Carvalho de Melo
2011-11-09 12:33 ` Arnaldo Carvalho de Melo
2011-11-09 12:46 ` Peter Zijlstra
2011-11-09 12:46 ` [Qemu-devel] " Peter Zijlstra
2011-11-09 12:46 ` Peter Zijlstra
2011-11-09 12:51 ` Arnaldo Carvalho de Melo
2011-11-09 12:51 ` [Qemu-devel] " Arnaldo Carvalho de Melo
2011-11-09 12:51 ` Arnaldo Carvalho de Melo
2011-11-09 13:17 ` Ingo Molnar
2011-11-09 13:17 ` [Qemu-devel] " Ingo Molnar
2011-11-09 19:25 ` Jim Paris
2011-11-09 19:25 ` [Qemu-devel] " Jim Paris
2011-11-09 19:25 ` Jim Paris
2011-11-09 20:13 ` Arnaldo Carvalho de Melo
2011-11-09 20:13 ` [Qemu-devel] " Arnaldo Carvalho de Melo
2011-11-09 20:13 ` Arnaldo Carvalho de Melo
2011-11-09 22:32 ` Anca Emanuel
2011-11-09 22:32 ` [Qemu-devel] " Anca Emanuel
2011-11-09 22:32 ` Anca Emanuel
2011-11-10 8:00 ` Ingo Molnar
2011-11-10 8:00 ` [Qemu-devel] " Ingo Molnar
2011-11-10 8:00 ` Ingo Molnar
2011-11-10 8:12 ` Anca Emanuel
2011-11-10 8:12 ` [Qemu-devel] " Anca Emanuel
2011-11-10 8:12 ` Anca Emanuel
2011-11-10 8:39 ` Gerd Hoffmann
2011-11-10 8:39 ` [Qemu-devel] " Gerd Hoffmann
2011-11-10 8:39 ` Gerd Hoffmann
2011-11-08 15:43 ` Steven Rostedt
2011-11-08 15:43 ` [Qemu-devel] " Steven Rostedt
2011-11-09 9:21 ` Ingo Molnar
2011-11-09 9:21 ` [Qemu-devel] " Ingo Molnar
2011-11-09 9:21 ` Ingo Molnar
2011-11-09 12:03 ` Arnaldo Carvalho de Melo
2011-11-09 12:03 ` [Qemu-devel] " Arnaldo Carvalho de Melo
2011-11-09 12:03 ` Arnaldo Carvalho de Melo
2011-11-09 13:40 ` Américo Wang
2011-11-09 13:40 ` [Qemu-devel] " Américo Wang
2011-11-10 7:47 ` Ingo Molnar
2011-11-10 7:47 ` [Qemu-devel] " Ingo Molnar
2011-11-10 7:47 ` Ingo Molnar
2011-11-07 10:31 ` [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels Kevin Wolf
2011-11-07 10:31 ` Kevin Wolf
2011-11-07 11:38 ` [Qemu-devel] " Pekka Enberg
2011-11-07 11:38 ` Pekka Enberg
2011-11-07 11:38 ` Pekka Enberg
2011-11-07 11:59 ` [Qemu-devel] " Kevin Wolf
2011-11-07 11:59 ` Kevin Wolf
2011-11-07 11:59 ` Kevin Wolf
2011-11-06 16:19 ` Jan Kiszka
2011-11-06 16:19 ` [Qemu-devel] " Jan Kiszka
2011-11-06 16:30 ` Pekka Enberg
2011-11-06 16:30 ` [Qemu-devel] " Pekka Enberg
2011-11-06 16:30 ` Pekka Enberg
2011-11-06 16:39 ` Jan Kiszka
2011-11-06 16:39 ` [Qemu-devel] " Jan Kiszka
2011-11-06 16:39 ` Jan Kiszka
2011-11-06 17:11 ` Pekka Enberg
2011-11-06 17:11 ` [Qemu-devel] " Pekka Enberg
2011-11-06 17:11 ` Pekka Enberg
2011-11-06 17:23 ` Jan Kiszka
2011-11-06 17:23 ` [Qemu-devel] " Jan Kiszka
2011-11-06 17:23 ` Jan Kiszka
2011-11-06 17:55 ` Pekka Enberg
2011-11-06 17:55 ` [Qemu-devel] " Pekka Enberg
2011-11-06 17:55 ` Pekka Enberg
2011-11-06 16:39 ` Pekka Enberg
2011-11-06 16:39 ` [Qemu-devel] " Pekka Enberg
2011-11-06 16:39 ` Pekka Enberg
2011-11-07 10:11 ` Gerd Hoffmann
2011-11-07 10:11 ` [Qemu-devel] " Gerd Hoffmann
2011-11-07 10:11 ` Gerd Hoffmann
2011-11-07 10:18 ` Pekka Enberg
2011-11-07 10:18 ` [Qemu-devel] " Pekka Enberg
2011-11-06 17:10 ` Anthony Liguori
2011-11-06 17:10 ` Anthony Liguori
2011-11-06 17:10 ` Anthony Liguori
2011-11-06 17:15 ` Alexander Graf
2011-11-06 17:15 ` [Qemu-devel] " Alexander Graf
2011-11-06 17:15 ` Alexander Graf
2011-11-06 17:28 ` Pekka Enberg
2011-11-06 17:28 ` [Qemu-devel] " Pekka Enberg
2011-11-06 17:28 ` Pekka Enberg
2011-11-06 17:30 ` Alexander Graf
2011-11-06 17:30 ` [Qemu-devel] " Alexander Graf
2011-11-06 17:30 ` Alexander Graf
2011-11-06 18:05 ` Pekka Enberg
2011-11-06 18:05 ` [Qemu-devel] " Pekka Enberg
2011-11-06 18:05 ` Pekka Enberg
2011-11-06 19:14 ` Paolo Bonzini
2011-11-06 19:14 ` [Qemu-devel] " Paolo Bonzini
2011-11-06 19:14 ` Paolo Bonzini
2011-11-06 19:19 ` Pekka Enberg
2011-11-06 19:19 ` [Qemu-devel] " Pekka Enberg
2011-11-06 19:19 ` Pekka Enberg
2011-11-06 22:08 ` Frank Ch. Eigler
2011-11-06 22:08 ` [Qemu-devel] " Frank Ch. Eigler
2011-11-06 22:08 ` Frank Ch. Eigler
2011-11-07 6:58 ` Pekka Enberg
2011-11-07 6:58 ` [Qemu-devel] " Pekka Enberg
2011-11-07 6:58 ` Pekka Enberg
2011-11-06 19:11 ` Paolo Bonzini
2011-11-06 19:11 ` [Qemu-devel] " Paolo Bonzini
2011-11-06 19:11 ` Paolo Bonzini
2011-11-06 19:17 ` Pekka Enberg
2011-11-06 19:17 ` [Qemu-devel] " Pekka Enberg
2011-11-06 20:01 ` Paolo Bonzini
2011-11-06 20:01 ` [Qemu-devel] " Paolo Bonzini
2011-11-06 20:01 ` Paolo Bonzini
2011-11-06 20:17 ` Pekka Enberg
2011-11-06 20:17 ` [Qemu-devel] " Pekka Enberg
2011-11-06 20:17 ` Pekka Enberg
2011-11-07 8:00 ` Paolo Bonzini
2011-11-07 8:00 ` [Qemu-devel] " Paolo Bonzini
2011-11-07 8:00 ` Paolo Bonzini
2011-11-07 8:09 ` Pekka Enberg
2011-11-07 8:09 ` [Qemu-devel] " Pekka Enberg
2011-11-07 8:09 ` Pekka Enberg
2011-11-07 8:20 ` Paolo Bonzini
2011-11-07 8:20 ` [Qemu-devel] " Paolo Bonzini
2011-11-07 8:20 ` Paolo Bonzini
2011-11-07 8:45 ` Pekka Enberg
2011-11-07 8:45 ` [Qemu-devel] " Pekka Enberg
2011-11-07 8:45 ` Pekka Enberg
2011-11-07 8:52 ` Paolo Bonzini
2011-11-07 8:52 ` [Qemu-devel] " Paolo Bonzini
2011-11-07 8:52 ` Paolo Bonzini
2011-11-07 8:57 ` Pekka Enberg
2011-11-07 8:57 ` [Qemu-devel] " Pekka Enberg
2011-11-07 8:57 ` Pekka Enberg
2011-11-07 8:13 ` Pekka Enberg
2011-11-07 8:13 ` [Qemu-devel] " Pekka Enberg
2011-11-07 8:13 ` Pekka Enberg
2011-11-06 20:31 ` Pekka Enberg
2011-11-06 20:31 ` [Qemu-devel] " Pekka Enberg
2011-11-06 20:31 ` Pekka Enberg
2011-11-07 10:23 ` Gerd Hoffmann
2011-11-07 10:23 ` [Qemu-devel] " Gerd Hoffmann
2011-11-07 10:23 ` Gerd Hoffmann
2011-11-07 10:30 ` [Qemu-devel] " Sasha Levin
2011-11-07 10:30 ` Sasha Levin
2011-11-07 10:30 ` Sasha Levin
2011-11-07 11:02 ` Paolo Bonzini
2011-11-07 11:02 ` [Qemu-devel] " Paolo Bonzini
2011-11-07 11:02 ` Paolo Bonzini
2011-11-07 11:44 ` Pekka Enberg
2011-11-07 11:44 ` [Qemu-devel] " Pekka Enberg
2011-11-07 11:44 ` Pekka Enberg
2011-11-07 12:18 ` Gerd Hoffmann
2011-11-07 12:18 ` [Qemu-devel] " Gerd Hoffmann
2011-11-07 12:18 ` Gerd Hoffmann
2011-11-07 12:21 ` Pekka Enberg
2011-11-07 12:21 ` [Qemu-devel] " Pekka Enberg
2011-11-07 12:21 ` Pekka Enberg
2011-11-07 12:26 ` [Qemu-devel] " Avi Kivity
2011-11-07 12:26 ` Avi Kivity
2011-11-07 12:26 ` Avi Kivity
2011-11-07 12:29 ` [Qemu-devel] " Pekka Enberg
2011-11-07 12:29 ` Pekka Enberg
2011-11-07 12:29 ` Pekka Enberg
2011-11-07 12:43 ` [Qemu-devel] " Ted Ts'o
2011-11-07 12:43 ` Ted Ts'o
2011-11-07 12:43 ` Ted Ts'o
2011-11-07 12:44 ` [Qemu-devel] " Avi Kivity
2011-11-07 12:44 ` Avi Kivity
2011-11-07 12:44 ` Avi Kivity
2011-11-07 11:34 ` Pekka Enberg
2011-11-07 11:34 ` [Qemu-devel] " Pekka Enberg
2011-11-07 11:57 ` Ingo Molnar
2011-11-07 11:57 ` [Qemu-devel] " Ingo Molnar
2011-11-07 11:57 ` Ingo Molnar
2011-11-07 13:17 ` [Qemu-devel] " Anthony Liguori
2011-11-07 13:17 ` Anthony Liguori
2011-11-07 12:08 ` Gerd Hoffmann
2011-11-07 12:08 ` [Qemu-devel] " Gerd Hoffmann
2011-11-07 12:29 ` Ted Ts'o
2011-11-07 12:29 ` [Qemu-devel] " Ted Ts'o
2011-11-07 12:42 ` Pekka Enberg
2011-11-07 12:42 ` Pekka Enberg
2011-11-07 12:42 ` [Qemu-devel] " Pekka Enberg
2011-11-07 12:47 ` Ted Ts'o
2011-11-07 12:47 ` [Qemu-devel] " Ted Ts'o
2011-11-07 12:47 ` Ted Ts'o
2011-11-07 12:59 ` Pekka Enberg
2011-11-07 12:59 ` [Qemu-devel] " Pekka Enberg
2011-11-07 12:59 ` Pekka Enberg
2011-11-07 13:12 ` Pekka Enberg
2011-11-07 13:12 ` Pekka Enberg
2011-11-07 13:12 ` [Qemu-devel] " Pekka Enberg
2011-11-08 13:29 ` Karel Zak
2011-11-08 13:29 ` [Qemu-devel] " Karel Zak
2011-11-08 14:30 ` Pekka Enberg
2011-11-08 14:30 ` [Qemu-devel] " Pekka Enberg
2011-11-08 14:30 ` Pekka Enberg
2011-11-06 13:11 ` Pekka Enberg
2011-11-06 13:11 ` [Qemu-devel] " Pekka Enberg
2011-11-06 13:11 ` Pekka Enberg
2011-11-06 17:09 ` Alexander Graf
2011-11-06 17:09 ` [Qemu-devel] " Alexander Graf
2011-11-06 12:27 ` Pekka Enberg
2011-11-06 12:27 ` [Qemu-devel] " Pekka Enberg
2011-11-06 12:27 ` Pekka Enberg
2011-11-08 14:41 ` Avi Kivity
2011-11-08 14:41 ` [Qemu-devel] " Avi Kivity
2011-11-08 14:52 ` Christoph Hellwig
2011-11-08 14:52 ` [Qemu-devel] " Christoph Hellwig
2011-11-08 14:55 ` Sasha Levin
2011-11-08 14:55 ` [Qemu-devel] " Sasha Levin
2011-11-08 14:55 ` Sasha Levin
2011-11-08 14:57 ` Avi Kivity
2011-11-08 14:57 ` [Qemu-devel] " Avi Kivity
2011-11-08 14:57 ` Avi Kivity
2011-11-08 14:59 ` Christoph Hellwig
2011-11-08 14:59 ` [Qemu-devel] " Christoph Hellwig
2011-11-08 17:34 ` Alexander Graf
2011-11-08 17:34 ` [Qemu-devel] " Alexander Graf
2011-11-08 17:36 ` Avi Kivity
2011-11-08 17:36 ` [Qemu-devel] " Avi Kivity
2011-11-08 15:04 ` Jan Kiszka
2011-11-08 15:04 ` [Qemu-devel] " Jan Kiszka
2011-11-08 15:26 ` Pekka Enberg
2011-11-08 15:26 ` [Qemu-devel] " Pekka Enberg
2011-11-08 15:26 ` Pekka Enberg
2011-11-08 15:28 ` Christoph Hellwig
2011-11-08 15:28 ` [Qemu-devel] " Christoph Hellwig
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=20111109083812.GC11473@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=agraf@suse.de \
--cc=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=jkacur@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=vince@deater.net \
--cc=xiyou.wangcong@gmail.com \
/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.