From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MDAWE-0008Rv-MF
	for qemu-devel@nongnu.org; Sun, 07 Jun 2009 01:02:06 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MDAW8-0008L5-U4
	for qemu-devel@nongnu.org; Sun, 07 Jun 2009 01:02:05 -0400
Received: from [199.232.76.173] (port=43571 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MDAW8-0008Kb-Go
	for qemu-devel@nongnu.org; Sun, 07 Jun 2009 01:02:00 -0400
Received: from mx2.redhat.com ([66.187.237.31]:57656)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1MDAW7-0003EY-HX
	for qemu-devel@nongnu.org; Sun, 07 Jun 2009 01:01:59 -0400
Message-ID: <4A2B49C0.8020703@redhat.com>
Date: Sun, 07 Jun 2009 08:01:52 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <4A26F1E3.1040509@codemonkey.ws>	<CF1C05DA-9F70-4469-B614-7F9E147E5992@web.de>	<4A2A92FE.2010700@redhat.com>
	<f43fc5580906060929j4d2fdd9fm46c8ee2d1cf7248c@mail.gmail.com>
	<4A2AA10B.6060401@web.de>
In-Reply-To: <4A2AA10B.6060401@web.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: POLL: Why do you use kqemu?
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Blue Swirl <blauwirbel@gmail.com>, =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <andreas.faerber@web.de>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

Jan Kiszka wrote:
>> Maybe the backwards compatibility features should be ported to QEMU?
>> For example, is there a workaround for
>> #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
>> ?
>>     
>
> Given that we have always-up-to-date kvm-kmod packages with support down
> to reasonable kernel versions, I would prefer to keep upstream clean
> from old workarounds. They should only be needed for issues found very
> recently (KVM_CAP_JOIN_MEMORY_REGIONS_WORKS) or that might be found in
> the future.
>   

Requiring the latest up-to-date modules is pushing the problem to the 
users.  Sometimes there is no choice, but when there is, the 
implementation that cares about its uses prefer unclean code and 
functionality over perfection and brokenness.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.