From: Avi Kivity <avi@redhat.com>
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 10:52:48 +0300 [thread overview]
Message-ID: <49FE9ED0.7060301@redhat.com> (raw)
In-Reply-To: <49FE0E97.30602@codemonkey.ws>
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.
> <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?
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.
next prev parent reply other threads:[~2009-05-04 7:53 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-03 21:37 [RFC] Bring in all the Linux headers we depend on in QEMU Anthony Liguori
2009-05-04 6:51 ` [Qemu-devel] " Stefan Weil
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 [this message]
2009-05-04 9:35 ` Paul Brook
2009-05-04 13:14 ` Anthony Liguori
2009-05-04 9:08 ` 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 ` [Qemu-devel] " 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 ` [Qemu-devel] " 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=49FE9ED0.7060301@redhat.com \
--to=avi@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.