Re: [RFC] Bring in all the Linux headers we depend on in QEMU
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.
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?
Thinking again about it, this is not really necessary.
In general a distro provides kernel headers matched to the running
kernel. For example F10 provides
kernel-headers-2.6.27.21-170.2.56.fc10.x86_64 to go along with
kernel-2.6.27.21-170.2.56.fc10.x86_64. So a user running a distro
kernel (the majority, given that most people don't inflict pain upon
themselves unnecessarily) will have exactly the features exported by the
kernel.
If a user compiles their own kernel, they will also have the complete
kernel sources. We could use --kerneldir, perhaps requiring that the
user do a 'make headers-install' first and point kerneldir to the result.
The only deviation for this is kvm, which also comes as an external
kernel module and therefore cannot rely on the installed kernel
headers. We could make the external module package (kvm-kmod) supply
its own set of headers and install them somewhere, or we can carry them
in qemu (much more convenient). But I don't think we need to carry such
a large subset of the kernel headers (which is liable to change as
kernel headers are added).
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Bring in all the Linux headers we depend on in QEMU
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Bring in all the Linux headers we depend on in QEMU
On Monday 04 May 2009, Mark McLoughlin wrote: Right, but if you e.g. try to build a newer qemu-kvm on F10, you currently need newer kvm kernel headers - IMHO, we should use #ifdef to allow newer qemu-kvm build with older kvm headers. I think the kvm and virtio headers should just be shipped with qemu-kvm in their latest versions, rather than relying on the ones from the kernel. Everything else should come from the distro-supplied glibc kernel headers. Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Bring in all the Linux headers we depend on in QEMU
Arnd Bergmann wrote: On Monday 04 May 2009, Mark McLoughlin wrote: Right, but if you e.g. try to build a newer qemu-kvm on F10, you currently need newer kvm kernel headers - IMHO, we should use #ifdef to allow newer qemu-kvm build with older kvm headers. I think the kvm and virtio headers should just be shipped with qemu-kvm in their latest versions, rather than relying on the ones from the kernel. Everything else should come from the distro-supplied glibc kernel headers. Just to reiterate, because I should have mentioned it in the original note, we need virtio to be buildable on non-Linux systems so those headers must not depend on having distro glibc headers. Regards, Anthony Liguori Arnd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Bring in all the Linux headers we depend on in QEMU
Anthony Liguori wrote: 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. If we want to use virtio_*.h instead of duplicating the copies as we are now, then we need all of the core headers too or else it won't be able to compile on systems that do not have Linux libc headers (like win32). qemu provides virtio, it doesn't consume it. We can merge the virtio headers and remove the linuxisms. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: [RFC] Bring in all the Linux headers we depend on in QEMU
On Mon, May 04, 2009 at 04:38:12PM +0300, Avi Kivity wrote: qemu provides virtio, it doesn't consume it. We can merge the virtio headers and remove the linuxisms. Yeah. virtio is a one the (virtual) wire protocol, not a kernel ABI in the tradition sense. qemu should have it's own defintion. For kernel feature qemu uses (mostly kvm, but also the scsi generic ioctl for example) it should just use the installed kernel headers, and not build the feature if they are too old. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Bring in all the Linux headers we depend on in QEMU
Anthony Liguori wrote: Thinking again about it, this is not really necessary. In general a distro provides kernel headers matched to the running kernel. For example F10 provides kernel-headers-2.6.27.21-170.2.56.fc10.x86_64 to go along with kernel-2.6.27.21-170.2.56.fc10.x86_64. So a user running a distro kernel (the majority, given that most people don't inflict pain upon themselves unnecessarily) will have exactly the features exported by the kernel. kernel-headers is not usually installed by default. It is: $ rpm -q --whatrequires kernel-headers glibc-headers-2.9-3.x86_64 -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Bring in all the Linux headers we depend on in QEMU
Arnd Bergmann wrote: 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. Distros that were released before 2006 certainly had this problem. The issue is that usbdevice_fs.h depends on __user. +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. If we want to use virtio_*.h instead of duplicating the copies as we are now, then we need all of the core headers too or else it won't be able to compile on systems that do not have Linux libc headers (like win32). +# 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. Yes, if it isn't clear, this Makefile is meant to be used by the maintainers to bring the headers into git. I didn't post the headers because it would have made the note annoyingly long. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: [RFC] Bring in all the Linux headers we depend on in QEMU
Mark McLoughlin wrote: On Mon, 2009-05-04 at 12:08 +0300, Avi Kivity wrote: In general a distro provides kernel headers matched to the running kernel. For example F10 provides kernel-headers-2.6.27.21-170.2.56.fc10.x86_64 to go along with kernel-2.6.27.21-170.2.56.fc10.x86_64. So a user running a distro kernel (the majority, given that most people don't inflict pain upon themselves unnecessarily) will have exactly the features exported by the kernel. Right, but if you e.g. try to build a newer qemu-kvm on F10, you currently need newer kvm kernel headers - IMHO, we should use #ifdef to allow newer qemu-kvm build with older kvm headers. qemu build against new headers should work fine on older hosts -- we discover features at runtime. But I agree it's nice to be able to build against older headers. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Bring in all the Linux headers we depend on in QEMU
Avi Kivity wrote: Anthony Liguori wrote: Comments? Thinking again about it, this is not really necessary. In general a distro provides kernel headers matched to the running kernel. For example F10 provides kernel-headers-2.6.27.21-170.2.56.fc10.x86_64 to go along with kernel-2.6.27.21-170.2.56.fc10.x86_64. So a user running a distro kernel (the majority, given that most people don't inflict pain upon themselves unnecessarily) will have exactly the features exported by the kernel. kernel-headers is not usually installed by default. Also, I'd rather not deal with #ifdef code as we introduce new features like TUN_VNET_HDR. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
