[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QE

From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] [RFC] Bring in all the Linux headers we depend on in QEMU
Date: Mon, 4 May 2009 10:17:56 +0200
User-agent: Mutt/1.5.16 (2007-06-09)

On Mon, May 04, 2009 at 08:51:21AM +0200, Stefan Weil wrote:
> 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.

I agree. The kvm issue seems unfortunate and I don't have any suggestions
on how to avoid it in the future but for other issues, like restructured
header files or renamed struct members etc I think there is a risk we
become sloppy in keeping up to date with current practices.

I don't feel very strongly about it but my gut feeling tells me we
shouldn't be doing this.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]