qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.

  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 [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU Anthony Liguori
2009-05-04  6:51 ` 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 ` [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=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 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).