linux-kernel - Re: [GIT PULL] Native Linux KVM tool for 3.1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOJsxLGvx=PQOqq--26k794SHdjDVOa7vhmNDKQt0jmfLbVRiQ@mail.gmail.com>
Date:	Mon, 25 Jul 2011 22:43:58 +0300
From:	Pekka Enberg <penberg@...nel.org>
To:	Jan Kiszka <jan.kiszka@....de>
Cc:	torvalds@...ux-foundation.org, mingo@...e.hu, avi@...hat.com,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, gorcunov@...il.com, levinsasha928@...il.com,
	asias.hejun@...il.com, prasadjoshi124@...il.com
Subject: Re: [GIT PULL] Native Linux KVM tool for 3.1

On Mon, Jul 25, 2011 at 9:24 PM, Jan Kiszka <jan.kiszka@....de> wrote:
>> On Mon, Jul 25, 2011 at 2:12 AM, Jan Kiszka <jan.kiszka@....de> wrote:
>>> I've read several times now that developing in a single tree leads to
>>> better results. Can you provide some example from the QEMU/KVM projects
>>> where the split is preventing innovation, optimizations, or some other
>>> kind of progress?
>>
>> I really don't follow the Qemu project well enough to comment on what
>> your biggest pain points are there.
>
> Mmh, you can solve problems you do not even need to know about, just by
> merging them into the kernel? Wait, will send you some more! :)

Don't be an idiot.

Qemu's problems are pretty well understood and many of them explained
in this particular thread. I'm not trying to fix Qemu's problems nor
am I trying to fix your Windows virtualization issues. I'm trying to
implement tooling to support Linux on KVM well enough that I don't
have to use VirtualBox for virtualization myself.

>> As for tools/kvm, it's pretty obvious by now that we want tighter
>> integration with perf and the tracing facilities (and share code!),
>> for example so for us merging to mainline is important.
>
> Tracing&profiling are important topics, but in the end just small pieces
> of the virtualization problem space. If that was the strongest reason,
> it would be like asking gdb guys to merge qemu because it contains a
> gdbserver.

I think that just shows that you don't really understand the benefits
of integrating KVM and perf.

> Anyway. Thanks for all the fish! Found nothing new, not much concrete,
> but many really entertaining answers. So why not repeat this on the next
> merge window?

While it's entertaining for you, it's not so much for me. I think we
have something pretty useful and cool in tools/kvm but all you seem to
want to talk about is Qemu which I personally find pretty
uninteresting.

Anyway, it's really up to Linus. FWIW, Avi doesn't oppose to the
merging and Ingo seems to think it's useful enough to have in -tip.

                        Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/