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

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

 



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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux