On Nov 8, 2011, at 4:32 AM, Ingo Molnar wrote:
No ifs and when about it, these are the plain facts:
- Better features, better ABIs: perf maintainers can enforce clean,
functional and usable tooling support *before* committing to an
ABI on the kernel side.
We don't have to be
On Nov 8, 2011, at 5:22 AM, Ingo Molnar wrote:
We do even more than that, the perf ABI is fully backwards *and*
forwards compatible: you can run older perf on newer ABIs and newer
perf on older ABIs.
It's great to hear that! But in that case, there's an experiment we can't
really run,
On Nov 8, 2011, at 6:20 AM, Pekka Enberg wrote:
We have the staging tree because it's a widely acknowledged belief that
kernel code in the tree tends to improve over time compared to code that's
sitting out of the tree. Are you disputing that belief?
Kernel code in the kernel source tree
On Nov 7, 2011, at 5:19 PM, Anthony Liguori wrote:
The kernel ecosystem does not have to be limited to linux.git. There could
be a process to be a kernel.org project for projects that fit a certain set
of criteria. These projects could all share the Linux kernel release cadence
and
On Sun, Aug 02, 2009 at 06:49:01PM +0300, Avi Kivity wrote:
What's the host kernel version?
We had problems with CONFIG_KVM_GUEST and PAE which were resolved in
2.6.30-final but perhaps failed to trickle down to whatever you're
using. The upstream commit is a8cd0244 (KVM: Make paravirt
