From: Arnd Bergmann <arnd@arndb.de>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
kvm-devel <kvm@vger.kernel.org>, Avi Kivity <avi@redhat.com>
Subject: Re: [RFC] Bring in all the Linux headers we depend on in QEMU
Date: Mon, 4 May 2009 13:29:30 +0200 [thread overview]
Message-ID: <200905041329.30824.arnd@arndb.de> (raw)
In-Reply-To: <49FE0E97.30602@codemonkey.ws>
On Sunday 03 May 2009, Anthony Liguori wrote:
> 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.
Can you clarify this? I can't find any version of usbdevice_fs.h that
ever included linux/compiler.h (make headers_check would warn about that),
and the only construct used in there that comes from compiler.h is
the __user annotation, which gets stripped in 'make headers_install',
and has been since 2006.
> +# Linux kernel headers CFLAGS
> +if test -z "$kerneldir" ; then
> + linux_cflags="-I$source_path/linux"
> +else
> + linux_cflags="-I$kerneldir/include"
> + if test \( "$cpu" = "i386" -o "$cpu" = "x86_64" \) \
> + -a -d "$kerneldir/arch/x86/include" ; then
> + linux_cflags="$linux_cflags -I$kerneldir/arch/x86/include"
> + elif test "$cpu" = "ppc" -a -d "$kerneldir/arch/powerpc/include" ;
> then + linux_cflags="$linux_cflags -I$kerneldir/arch/powerpc/include"
> + elif test -d "$kerneldir/arch/$cpu/include" ; then
> + linux_cflags="$linux_cflags -I$kerneldir/arch/$cpu/include"
> + fi
> +fi
arch/*/include is not the right place to look for user headers.
I think it would be better to assume that the user only points to
valid exported headers, so look for linux/version.h to check that
the files have been configured and look for the absense of
kvm_host.h to make sure that the user did not point to plain
kernel sources.
The exported headers already handle the asm/ links correctly, so
I think you never need to do anything architecture specific
like your fixup.sed.
> +CORE_HDRS=linux/types.h linux/posix_types.h linux/stddef.h linux/compiler.h
> +CORE_HDRS+=linux/byteorder/little_endian.h linux/byteorder/big_endian.h
> +CORE_HDRS+=linux/swab.h linux/ioctl.h
> +
> +CORE_HDRS+=asm-generic/int-ll64.h asm-generic/int-l64.h asm-generic/ioctl.h
> +
> +CORE_HDRS+=asm-x86/types.h asm-x86/posix_types.h
> +CORE_HDRS+=asm-x86/posix_types_32.h asm-x86/posix_types_64.h
> +CORE_HDRS+=asm-x86/byteorder.h asm-x86/swab.h asm-x86/ioctl.h
> +
> +CORE_HDRS+=asm-powerpc/types.h asm-powerpc/posix_types.h
> +CORE_HDRS+=asm-powerpc/byteorder.h asm-powerpc/swab.h asm-powerpc/ioctl.h
> +
> +CORE_HDRS+=asm-sparc/types.h asm-sparc/posix_types.h
> +CORE_HDRS+=asm-sparc/byteorder.h asm-sparc/swab.h asm-sparc/ioctl.h
> +CORE_HDRS+=asm-sparc/asi.h
> +
> +CORE_HDRS+=asm-arm/types.h asm-arm/posix_types.h
> +CORE_HDRS+=asm-arm/byteorder.h asm-arm/swab.h asm-arm/ioctl.h
> +
> +CORE_HDRS+=asm-parisc/types.h asm-parisc/posix_types.h
> +CORE_HDRS+=asm-parisc/byteorder.h asm-parisc/swab.h asm-parisc/ioctl.h
I don't see the need to copy all the core headers. These should have
been working for ages, and hardly ever see changes that are relevant
to kvm.
The exceptions are linux/stddef.h and linux/compiler.h, which are
not exported and should never be used outside of the kernel.
> +# Kernel Virtual Machine interface
> +KVM_HDRS=linux/kvm.h linux/kvm_para.h
> +KVM_HDRS+=asm-x86/kvm.h asm-x86/kvm_para.h
> +KVM_HDRS+=asm-powerpc/kvm.h asm-powerpc/kvm_para.h
> +
> +# VirtIO paravirtual IO framework
> +VIRTIO_HDRS=linux/virtio_config.h linux/virtio_net.h linux/virtio_blk.h
> +VIRTIO_HDRS+=linux/virtio_console.h linux/virtio_balloon.h
These should be copied into the qemu source tree, but not at configure
time. They should just reflect the latest upstream version. Qemu already
needs to handle older kernel versions at run time, and by having the
very latest version in the source tree, you can make sure that qemu
will run on any kernel version.
For asm/kvm.h and asm/kvm-para.h, you can have hard-coded files
multiplexing between the architectures, as you would otherwise
generate from your fixup.sed.
> +# tun/tap interfaces
> +TUN_HDRS=linux/if_tun.h linux/if_ether.h
> +
> +# timers
> +TIMER_HDRS=linux/rtc.h linux/hpet.h
> +
> +# USB pass through
> +USB_HDRS=linux/usbdevice_fs.h linux/magic.h
> +
> +# IDE/FD
> +DISK_HDRS=linux/cdrom.h linux/fd.h
> +
> +# Parallel port
> +PPORT_HDRS=linux/ppdev.h linux/parport.h
For all of these, I would again fall back on the distro-provided
headers. You might not get the latest versions, but at least you
can assume that any kernel that the distro provides will also
at least support the ABI from these headers.
Arnd <><
next prev parent reply other threads:[~2009-05-04 11:29 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
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 [this message]
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=200905041329.30824.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--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