From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M0s1Z-0006v9-ST for qemu-devel@nongnu.org; Mon, 04 May 2009 02:51:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M0s1U-0006ul-S1 for qemu-devel@nongnu.org; Mon, 04 May 2009 02:51:36 -0400 Received: from [199.232.76.173] (port=39965 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M0s1U-0006ui-Kn for qemu-devel@nongnu.org; Mon, 04 May 2009 02:51:32 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]:59729) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M0s1T-0003Ci-Ng for qemu-devel@nongnu.org; Mon, 04 May 2009 02:51:32 -0400 Message-ID: <49FE9069.7010201@mail.berlios.de> Date: Mon, 04 May 2009 08:51:21 +0200 From: Stefan Weil 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 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 schrieb: > 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? > > Regards, > > Anthony Liguori For Debian systems, those headers are installed by package linux-libc-dev. There are also packages for cross compilation in emdebian (linux-libc-dev-mips-cross, linux-libc-dev-powerpc-cross, ...). Yes, those headers did not always match the features of the current kernel, so --enable-kvm did not work. This is fixed now - there is a linux-libc-dev 2.6.29-3 which is up-to-date. So, at the moment I see no need to fill the QEMU source tree with linux header files. For special needs the configure option (--kerneldir=PATH) should be sufficient. Regards Stefan Weil