From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36618 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoJgW-0002Hv-UI for qemu-devel@nongnu.org; Wed, 25 Aug 2010 13:22:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OoJgV-0005gq-S3 for qemu-devel@nongnu.org; Wed, 25 Aug 2010 13:22:48 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:35566) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OoJgV-0005gk-O1 for qemu-devel@nongnu.org; Wed, 25 Aug 2010 13:22:47 -0400 Message-ID: <4C755165.4040804@mentor.com> Date: Wed, 25 Aug 2010 10:22:45 -0700 From: Hollis Blanchard MIME-Version: 1.0 Subject: Re: [Qemu-devel] vhost_net.c broken by --kerneldir References: <4C746A1E.6070000@mentor.com> <201008251537.27679.arnd@arndb.de> In-Reply-To: <201008251537.27679.arnd@arndb.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Arnd Bergmann Cc: qemu-devel@nongnu.org, mst@redhat.com On 08/25/2010 06:37 AM, Arnd Bergmann wrote: > On Wednesday 25 August 2010, Hollis Blanchard wrote: > >> The problem seems to be that jump from /usr/include/bits/sigcontext.h to >> asm/sigcontext.h inside rather than inside /usr/include. It >> seems like adding -Ikerneldir/arch/foo/include will always be a problem, >> since it will always be used to satisfy "#include". Only >> files built with KVM_CFLAGS would be affected, and I guess vhost_net.c >> accidentally gets into a broken include path where the other KVM_CFLAGS >> files doesn't. >> >> I'm wondering why this isn't causing more problems for more people. My >> host is Fedora 12, FWIW, but this doesn't seem like it could at all be >> related to toolchain version, for example. >> > 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. Hollis Blanchard Mentor Graphics, Embedded Systems Division