From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0szT-0003tI-NH for qemu-devel@nongnu.org; Mon, 04 May 2009 03:53:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0szQ-0003rA-3k for qemu-devel@nongnu.org; Mon, 04 May 2009 03:53:31 -0400 Received: from [199.232.76.173] (port=39882 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0szP-0003r4-OC for qemu-devel@nongnu.org; Mon, 04 May 2009 03:53:27 -0400 Received: from mx20.gnu.org ([199.232.41.8]:14536) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M0szP-0000Ci-4g for qemu-devel@nongnu.org; Mon, 04 May 2009 03:53:27 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M0szO-0008G6-7n for qemu-devel@nongnu.org; Mon, 04 May 2009 03:53:26 -0400 Message-ID: <49FE9ED0.7060301@redhat.com> Date: Mon, 04 May 2009 10:52:48 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU References: <49FE0E97.30602@codemonkey.ws> In-Reply-To: <49FE0E97.30602@codemonkey.ws> 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: Anthony Liguori Cc: "qemu-devel@nongnu.org" , kvm-devel Anthony Liguori wrote: > Sorry this explanation is long winded, but this is a messy situation. > > In Linux, there isn't a very consistent policy about userspace kernel > header inclusion. On a typical Linux system, you're likely to find > kernel headers in three places. > > glibc headers (/usr/include/{linux,asm}) > > These headers are installed by glibc. They very often are based on > much older kernel versions that the kernel you have in your > distribution. For software that depends on these headers, very often > this means that your software detects features being missing that are > present on your kernel. Furthermore, glibc only installs the headers > it needs so very often certain headers have dependencies that aren't > met. A classic example is linux/compiler.h and the broken > usbdevice_fs.h header that depends on it. There are still > distributions today that QEMU doesn't compile on because of this. > > Today, most of QEMU's code depends on these headers. > > /lib/modules/$(uname -r)/build > > These are the kernel headers that are installed as part of your > kernel. In general, this is a pretty good place to find the headers > that are associated with the kernel version you're actually running > on. However, these headers are part of the kernel build tree and are > not always guaranteed to be includable from userspace. > I thought these were for external modules, not for userspace. > > > Developers, in particular, like to point things at their random kernel > trees. In general though, relying on a full kernel source tree being > available isn't a good idea. Kernel headers change dramatically > across versions too so it's very likely that we would need to have a > lot of #ifdefs dependent on kernel versions, or some of the uglier > work arounds we have in usb-linux.c. > > I think the best way to avoid #ifdefs and dependencies on > broken/incomplete glibc headers is to include all of the Linux headers > we need within QEMU. The attached patch does just this. > > I think there's room for discussion about whether we really want to do > this. We could potentially depend on some more common glibc headers > (like asm/types.h) while bringing in less reliable headers > (if_tun.h/virtio*). Including them all seems like the most robust > solution to me though. > > Comments? I think we need to use the output of 'make headers-install', which removes things like __user and CONFIG_*. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.