From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0yC9-0004Ba-Fr for qemu-devel@nongnu.org; Mon, 04 May 2009 09:26:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0yC5-0004Au-CB for qemu-devel@nongnu.org; Mon, 04 May 2009 09:26:57 -0400 Received: from [199.232.76.173] (port=43933 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0yC5-0004Ar-82 for qemu-devel@nongnu.org; Mon, 04 May 2009 09:26:53 -0400 Received: from mx2.redhat.com ([66.187.237.31]:58457) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M0yC4-0005WV-Gn for qemu-devel@nongnu.org; Mon, 04 May 2009 09:26:52 -0400 Message-ID: <49FEECF5.9010509@redhat.com> Date: Mon, 04 May 2009 16:26:13 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC] Bring in all the Linux headers we depend on in QEMU References: <49FE0E97.30602@codemonkey.ws> <49FEB0A6.4080104@redhat.com> <1241440974.8777.38.camel@blaa> In-Reply-To: <1241440974.8777.38.camel@blaa> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark McLoughlin Cc: "qemu-devel@nongnu.org" , kvm-devel Mark McLoughlin wrote: > On Mon, 2009-05-04 at 12:08 +0300, Avi Kivity wrote: > >> In general a distro provides kernel headers matched to the running >> kernel. For example F10 provides >> kernel-headers-2.6.27.21-170.2.56.fc10.x86_64 to go along with >> kernel-2.6.27.21-170.2.56.fc10.x86_64. So a user running a distro >> kernel (the majority, given that most people don't inflict pain upon >> themselves unnecessarily) will have exactly the features exported by the >> kernel. >> > > Right, but if you e.g. try to build a newer qemu-kvm on F10, you > currently need newer kvm kernel headers - IMHO, we should use #ifdef to > allow newer qemu-kvm build with older kvm headers. > > qemu build against new headers should work fine on older hosts -- we discover features at runtime. But I agree it's nice to be able to build against older headers. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.