On Tue, 8 Nov 2011, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 08, 2011 at 01:07:55PM +0100, Ingo Molnar escreveu:
> > * Vince Weaver wrote:
> > > as mentioned before I have my own perf_event test suite with 20+ tests.
> > > http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.h
Em Tue, Nov 08, 2011 at 01:07:55PM +0100, Ingo Molnar escreveu:
> * Vince Weaver wrote:
> > as mentioned before I have my own perf_event test suite with 20+ tests.
> > http://web.eecs.utk.edu/~vweaver1/projects/perf-events/validation.html
> That should probably be moved into perf test. Arnaldo
* Vince Weaver wrote:
> On Mon, 7 Nov 2011, Ingo Molnar wrote:
> > I think we needed to do only one revert along the way in the past
> > two years, to fix an unintended ABI breakage in PowerTop.
> > Considering the total complexity of the perf ABI our
> > compatibility track record is *very*
On Mon, 7 Nov 2011, Ingo Molnar wrote:
> I think we needed to do only one revert along the way in the past two
> years, to fix an unintended ABI breakage in PowerTop. Considering the
> total complexity of the perf ABI our compatibility track record is
> *very* good.
There have been more breakag
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
>
On 11/07/2011 03:36 PM, Pekka Enberg wrote:
Hi Ted,
On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o wrote:
Personally, I consider code that runs in userspace as a pretty bright
line, as being "not kernel code", and while perhaps things like
initramfs and the crazy ideas people have had in the past o
Hi Ted,
On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o wrote:
> Personally, I consider code that runs in userspace as a pretty bright
> line, as being "not kernel code", and while perhaps things like
> initramfs and the crazy ideas people have had in the past of moving
> stuff out of kernel/init.c int
On Mon, Nov 07, 2011 at 10:09:34PM +0200, Pekka Enberg wrote:
>
> I guess for perf ABI, "perf test" is the closest thing to a
> specification so if your application is using something that's not
> covered by it, you might be in trouble.
I don't believe there's ever been any guarantee that "perf t
On Mon, Nov 07, 2011 at 09:53:28PM +0200, Pekka Enberg wrote:
>
> I'm sure perf developers break the ABI sometimes - that happens
> elsewhere in the kernel as well. However, Ted claimed that perf
> developers use tools/perf as an excuse to break the ABI _on purpose_
> which is something I have har
On Mon, 7 Nov 2011, Frank Ch. Eigler wrote:
The ABI design allows for that kind of flexible extensibility, and
it's one of its major advantages.
What we *cannot* protect against is you relying on obscure details of
the ABI [...]
Is there some documentation that clearly spells out which parts o
Ingo Molnar writes:
> [...]
>> It's problem enough that there's no way to know what version of the
>> perf_event abi you are running against and we have to guess based
>> on kernel version. This gets "fun" because all of the vendors have
>> backported seemingly random chunks of perf_event cod
On Mon, 7 Nov 2011, Pekka Enberg wrote:
>> I've never heard ABI incompatibility used as an argument for perf. Ingo?
On Mon, Nov 7, 2011 at 7:03 PM, Vince Weaver wrote:
> Never overtly. They're too clever for that.
If you want me to take you seriously, spare me from the conspiracy theories, OK?
* Vince Weaver wrote:
> On Mon, 7 Nov 2011, Pekka Enberg wrote:
>
> > I've never heard ABI incompatibility used as an argument for
> > perf. Ingo?
Correct, the ABI has been designed in a way to make it really hard to
break the ABI via either directed backports or other mess-ups.
The ABI is
On Mon, 7 Nov 2011, Pekka Enberg wrote:
> I've never heard ABI incompatibility used as an argument for perf. Ingo?
Never overtly. They're too clever for that.
In any case, as a primary developer of a library (PAPI) that uses the
perf_events ABI I have to say that having perf in the kernel has
On 11/07/2011 05:57 AM, Ingo Molnar wrote:
* Pekka Enberg wrote:
On Mon, 7 Nov 2011, Gerd Hoffmann wrote:
It's not just about code, it's as much about culture and development process.
Indeed. The BSDs have both kernel and the base system in a single
repository. There are probably good re
On 11/07/2011 02:29 PM, Pekka Enberg wrote:
> Hi Avi,
>
> On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity wrote:
> >> tools/power was merged in just 2 versions ago, do you think that
> >> merging that was a mistake?
> >
> > Things like tools/power may make sense, most of the code is tied to the
> > ker
On Mon, Nov 07, 2011 at 02:29:45PM +0200, Pekka Enberg wrote:
> So what do you think about perf then? The amount of code that talks to
> the kernel is much smaller than that of the KVM tool.
I think it's a mess, because it's never clear whether perf needs to be
upgraded when I upgrade the kernel,
Hi Avi,
On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity wrote:
>> tools/power was merged in just 2 versions ago, do you think that
>> merging that was a mistake?
>
> Things like tools/power may make sense, most of the code is tied to the
> kernel interfaces. tools/kvm is 20k lines and is likely to be
On 11/07/2011 12:30 PM, Sasha Levin wrote:
> On Mon, Nov 7, 2011 at 12:23 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> >> It's not just about code, it's as much about culture and development
> >> process.
> >
> > Indeed. The BSDs have both kernel and the base system in a single
> > repository. There
Am 07.11.2011 12:38, schrieb Pekka Enberg:
> On Mon, 7 Nov 2011, Kevin Wolf wrote:
>> Makes it a lot less hackable for me unless you want to restrict the set
>> of potential developers to Linux kernel developers...
>
> We're not restricting potential developers to Linux kernel folks. We're
> maki
On Mon, 7 Nov 2011, Kevin Wolf wrote:
Makes it a lot less hackable for me unless you want to restrict the set
of potential developers to Linux kernel developers...
We're not restricting potential developers to Linux kernel folks. We're
making it easy for them because we believe that the KVM to
On Mon, Nov 7, 2011 at 12:23 PM, Gerd Hoffmann wrote:
> Hi,
>
>> It's not just about code, it's as much about culture and development process.
>
> Indeed. The BSDs have both kernel and the base system in a single
> repository. There are probably good reasons for (and against) it.
>
> In Linux w
Am 06.11.2011 19:31, schrieb Ted Ts'o:
> On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote:
>> I'm quite happy with KVM tool and hope they continue working on it.
>> My only real wish is that they wouldn't copy QEMU so much and would
>> try bolder things that are fundamentally differe
Hi Anthony,
On Sun, 6 Nov 2011, Anthony Liguori wrote:
- Drop SDL/VNC. Make a proper Cairo GUI with a full blown GTK interface.
Don't rely on virt-manager for this. Not that I have anything against
virt-manager but there are many layers between you and the end GUI if you go
that route.
Fun
On Sun, 6 Nov 2011, Ted Ts'o wrote:
The only excuse I can see is a hope to make random changes to the
kernel and userspace tools without having to worry about compatibility
problems, which is an argument I've seen with perf (that you have to
use the same version of perf as the kernel version, whi
On 11/06/2011 12:09 PM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 7:08 PM, Anthony Liguori wrote:
I'm quite happy with KVM tool and hope they continue working on it. My only
real wish is that they wouldn't copy QEMU so much and would try bolder
things that are fundamentally different from QEM
On Sun, Nov 06, 2011 at 08:58:20PM +0200, Pekka Enberg wrote:
> > Ted, I'm confused. Making backwards incompatible ABI changes has never
> > been on the table. Why are you bringing it up?
>
> And btw, KVM tool is not a random userspace project - it was designed
> to live in tools/kvm from the begi
On Sun, Nov 6, 2011 at 8:54 PM, Pekka Enberg wrote:
>> So integrating kvm-tool into the kernel isn't going to work as a free
>> pass to make non-backwards compatible changes to the KVM user/kernel
>> interface. Given that, why bloat the kernel source tree size?
>
> Ted, I'm confused. Making backw
On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote:
>> I'm quite happy with KVM tool and hope they continue working on it.
>> My only real wish is that they wouldn't copy QEMU so much and would
>> try bolder things that are fundamentally different from QEMU.
On Sun, Nov 6, 2011 at 8:3
On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote:
> I'm quite happy with KVM tool and hope they continue working on it.
> My only real wish is that they wouldn't copy QEMU so much and would
> try bolder things that are fundamentally different from QEMU.
My big wish is that they don'
On Sun, Nov 6, 2011 at 7:08 PM, Anthony Liguori wrote:
> I'm quite happy with KVM tool and hope they continue working on it. My only
> real wish is that they wouldn't copy QEMU so much and would try bolder
> things that are fundamentally different from QEMU.
Hey, right now our only source of cra
On 11/06/2011 07:06 AM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity wrote:
You say that kvm-tool's scope is broader than Alex's script, therefore
the latter is pointless.
I'm saying that Alex's script is pointless because it's not attempting
to fix the real issues. For exam
On 11/06/2011 10:50 AM, Avi Kivity wrote:
On 11/06/2011 06:35 PM, Pekka Enberg wrote:
The difference here is that although I feel Alex's script is a
pointless project, I'm in no way opposed to merging it in the tree if
people use it and it solves their problem. Some people seem to be
violently o
Am 06.11.2011 02:35, schrieb Alexander Graf:
> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
> would be doing and what he expects from it. Basically he wants a
> small and simple tool he and other developers can run to try out and
> see if the kernel they just built actually w
On 25.08.2011, at 11:01, Blue Swirl wrote:
> On Wed, Aug 24, 2011 at 9:38 PM, Alexander Graf wrote:
>> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
>> would be doing and what he expects from it. Basically he wants a
>> small and simple tool he and other developers can run
On Wed, Aug 24, 2011 at 9:38 PM, Alexander Graf wrote:
> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
> would be doing and what he expects from it. Basically he wants a
> small and simple tool he and other developers can run to try out and
> see if the kernel they just built
On 24.08.2011, at 12:40, Blue Swirl wrote:
> On Tue, Aug 23, 2011 at 10:16 PM, Alexander Graf wrote:
>> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
>> would be doing and what he expects from it. Basically he wants a
>> small and simple tool he and other developers can run
On 08/24/2011 08:40 PM, Blue Swirl wrote:
> +
> + # Qemu's own build system calls it qemu-system-x86_64
> + [ "$QEMU_BIN" ] || QEMU_BIN=$(which qemu-system-x86_64 2>/dev/null)
If you run qemu-system-x86_64 on an i386 host, will it use kvm at all?
I think it will, and that's actu
On Tue, Aug 23, 2011 at 10:16 PM, Alexander Graf wrote:
> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
> would be doing and what he expects from it. Basically he wants a
> small and simple tool he and other developers can run to try out and
> see if the kernel they just buil
39 matches
Mail list logo
