From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0uBC-0002dC-VT for qemu-devel@nongnu.org; Mon, 04 May 2009 05:09:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0uB8-0002ZA-Kv for qemu-devel@nongnu.org; Mon, 04 May 2009 05:09:42 -0400 Received: from [199.232.76.173] (port=56855 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0uB8-0002Yt-Ae for qemu-devel@nongnu.org; Mon, 04 May 2009 05:09:38 -0400 Received: from mx2.redhat.com ([66.187.237.31]:51743) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M0uB7-00038m-CT for qemu-devel@nongnu.org; Mon, 04 May 2009 05:09:38 -0400 Message-ID: <49FEB0A6.4080104@redhat.com> Date: Mon, 04 May 2009 12:08:54 +0300 From: Avi Kivity MIME-Version: 1.0 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 Subject: [Qemu-devel] Re: [RFC] Bring in all the Linux headers we depend on in QEMU 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. > > > > 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? > Thinking again about it, this is not really necessary. 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. If a user compiles their own kernel, they will also have the complete kernel sources. We could use --kerneldir, perhaps requiring that the user do a 'make headers-install' first and point kerneldir to the result. The only deviation for this is kvm, which also comes as an external kernel module and therefore cannot rely on the installed kernel headers. We could make the external module package (kvm-kmod) supply its own set of headers and install them somewhere, or we can carry them in qemu (much more convenient). But I don't think we need to carry such a large subset of the kernel headers (which is liable to change as kernel headers are added). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.