From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43354 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoeH2-0007zv-GY for qemu-devel@nongnu.org; Thu, 26 Aug 2010 11:21:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OoeH0-0007uJ-8g for qemu-devel@nongnu.org; Thu, 26 Aug 2010 11:21:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5492) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OoeH0-0007ts-0X for qemu-devel@nongnu.org; Thu, 26 Aug 2010 11:21:50 -0400 Date: Thu, 26 Aug 2010 18:21:42 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] vhost_net.c broken by --kerneldir Message-ID: <20100826152142.GV10499@redhat.com> References: <4C746A1E.6070000@mentor.com> <201008251537.27679.arnd@arndb.de> <4C755165.4040804@mentor.com> <201008261715.36022.arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008261715.36022.arnd@arndb.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Arnd Bergmann Cc: Hollis Blanchard , qemu-devel@nongnu.org, mst@redhat.com On Thu, Aug 26, 2010 at 05:15:35PM +0200, Arnd Bergmann wrote: > On Wednesday 25 August 2010, Hollis Blanchard wrote: > > > We only recently fixed the kernel to have this warning in types.h, which > > > triggers more often than kernel.h, where it used to be before. In 2.6.35 > > > and before, you consequently would not have noticed the problem. > > > > > > > Thanks Arnd, that explains it. > > > > It looks like the --kerneldir option needs to be re-thought. > > Yes. I believe that we should just kill that option, since there is > no reason for building with set of headers from a different kernel > than the one your glibc normally uses. > > You obviously need copies of some headers to match qemu code, e.g. > the kvm headers, but for those we have run-time compatibility code > in qemu. Building with a newer kernel header is pointless because > qemu would not use any of the features that were added after the > release of the qemu tree you are trying to build. Building with > an older kernel header is equally pointless because all it would > do is to require #ifdef magic in qemu that ends up preventing you > from using all features of new kernels. > You forgot about developers. Developer may want to use latest kvm kernel headers to compile code that he added to qemu to use new kernel feature. -- Gleb.