From: Stefan Weil <weil@mail.berlios.de>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
kvm-devel <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU
Date: Mon, 04 May 2009 08:51:21 +0200 [thread overview]
Message-ID: <49FE9069.7010201@mail.berlios.de> (raw)
In-Reply-To: <49FE0E97.30602@codemonkey.ws>
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.
>
> <random kernel tree>
>
> 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
next prev parent reply other threads:[~2009-05-04 6:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-03 21:37 [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU Anthony Liguori
2009-05-04 6:51 ` Stefan Weil [this message]
2009-05-04 8:17 ` Edgar E. Iglesias
2009-05-04 13:15 ` Anthony Liguori
2009-05-04 13:44 ` Edgar E. Iglesias
2009-05-04 13:13 ` Anthony Liguori
2009-05-04 13:28 ` Avi Kivity
2009-05-04 13:30 ` Anthony Liguori
2009-05-04 14:01 ` Christoph Hellwig
2009-05-04 14:27 ` Lennart Sorensen
2009-05-04 7:52 ` Avi Kivity
2009-05-04 9:35 ` Paul Brook
2009-05-04 13:14 ` Anthony Liguori
2009-05-04 9:08 ` [Qemu-devel] " Avi Kivity
2009-05-04 12:42 ` Mark McLoughlin
2009-05-04 13:01 ` Arnd Bergmann
2009-05-04 13:25 ` Anthony Liguori
2009-05-04 13:26 ` Avi Kivity
2009-05-04 13:24 ` Anthony Liguori
2009-05-04 13:40 ` Avi Kivity
2009-05-04 11:29 ` Arnd Bergmann
2009-05-04 13:21 ` Anthony Liguori
2009-05-04 13:38 ` Avi Kivity
2009-05-04 14:04 ` Christoph Hellwig
2009-05-04 14:18 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49FE9069.7010201@mail.berlios.de \
--to=weil@mail.berlios.de \
--cc=anthony@codemonkey.ws \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).