qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH v2 17/17] kvm: Drop dependencies on very old cap


From: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH v2 17/17] kvm: Drop dependencies on very old capabilities
Date: Mon, 03 Jan 2011 19:01:55 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

On 01/03/2011 06:54 PM, Jan Kiszka wrote:
Am 03.01.2011 17:08, Avi Kivity wrote:
>  On 01/03/2011 10:33 AM, Jan Kiszka wrote:
>>  From: Jan Kiszka<address@hidden>
>>
>>  COALESCED_MMIO, SYNC_MMU, EXT_CPUID, CLOCKSOURCE, NOP_IO_DELAY, PV_MMU -
>>  all these caps predate features on which we already depend at build
>>  time. Moreover, the check for KVM_CAP_EXT_CPUID is unneeded as we
>>  already test&   fail is a more recent feature is missing.
>
>  No.  Each test documents a dependency of qemu on a kvm feature.  Even
>  though something like SYNC_MMU is unlikely to go away, as long as we
>  depend on it, we require the feature.
>

Then at least move all those KVM_CAPs we need at build time into
configure.

Need a run time check as well (build on new kernel, run on old kernel, or run on even newer kernel that lost a feature).

I really see no value in keeping ugly conditional code
around, A) because those paths won't be tested and B) none of the CAPs
touched here are to pass away without a replacement that will require
user space adaption anyway.

I'm fine with a series of checks during init time with no fallback. I'm not fine with just dropping those away. Reducing code size is great, but not at the cost of undiagnosed runtime failures.

--
error compiling committee.c: too many arguments to function




reply via email to

[Prev in Thread] Current Thread [Next in Thread]