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

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

[Anthony Liguori]

[-- Attachment #1: Type: text/plain, Size: 2230 bytes --]

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

[-- Attachment #2: 0001-Import-Linux-headers-into-QEMU.patch --]
[-- Type: text/x-patch, Size: 10288 bytes --]

>From b42aa57e94fc6b05897271b0816fa34d70670c9a Mon Sep 17 00:00:00 2001
From: Anthony Liguori <aliguori@us.ibm.com>
Date: Sat, 2 May 2009 15:45:24 -0500
Subject: [PATCH] Import Linux headers into QEMU

These are the headers from Linux 2.6.29 that have been modified to work under
QEMU.  This includes the necessary scripts to generate the headers from the
original Linux source tree.

I've not included the headers in this patch as they are quite big and would make
review more difficult.  I've included headers for all host architectures QEMU
currently supports but I've only tested x86.

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
 Makefile.target |    3 --
 configure       |   37 ++++++++++---------
 linux/Makefile  |  108 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 linux/README    |   19 ++++++++++
 linux/fixup.sed |   19 ++++++++++
 usb-linux.c     |    1 -
 6 files changed, 165 insertions(+), 22 deletions(-)
 create mode 100644 linux/Makefile
 create mode 100644 linux/README
 create mode 100644 linux/fixup.sed

diff --git a/Makefile.target b/Makefile.target
index f735105..474245a 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -124,9 +124,6 @@ CFLAGS+=-I/opt/SUNWspro/prod/include/cc
 endif
 endif
 
-kvm.o: CFLAGS+=$(KVM_CFLAGS)
-kvm-all.o: CFLAGS+=$(KVM_CFLAGS)
-
 all: $(PROGS)
 
 #########################################################
diff --git a/configure b/configure
index 82fb60a..379a2a6 100755
--- a/configure
+++ b/configure
@@ -1081,6 +1081,23 @@ EOF
   fi
 fi
 
+# 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
+
+OS_CFLAGS="$OS_CFLAGS $linux_cflags"
+
 ##########################################
 # kvm probe
 if test "$kvm" = "yes" ; then
@@ -1100,27 +1117,14 @@ if test "$kvm" = "yes" ; then
 #endif
 int main(void) { return 0; }
 EOF
-  if test "$kerneldir" != "" ; then
-      kvm_cflags=-I"$kerneldir"/include
-      if test \( "$cpu" = "i386" -o "$cpu" = "x86_64" \) \
-         -a -d "$kerneldir/arch/x86/include" ; then
-            kvm_cflags="$kvm_cflags -I$kerneldir/arch/x86/include"
-	elif test "$cpu" = "ppc" -a -d "$kerneldir/arch/powerpc/include" ; then
-	    kvm_cflags="$kvm_cflags -I$kerneldir/arch/powerpc/include"
-        elif test -d "$kerneldir/arch/$cpu/include" ; then
-            kvm_cflags="$kvm_cflags -I$kerneldir/arch/$cpu/include"
-      fi
-  else
-      kvm_cflags=""
-  fi
-  if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $kvm_cflags $TMPC \
+  if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC \
       > /dev/null 2>/dev/null ; then
     :
   else
     kvm="no";
     if [ -x "`which awk 2>/dev/null`" ] && \
        [ -x "`which grep 2>/dev/null`" ]; then
-      kvmerr=`LANG=C $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $kvm_cflags $TMPC 2>&1 \
+      kvmerr=`LANG=C $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC 2>&1 \
 	| grep "error: " \
 	| awk -F "error: " '{if (NR>1) printf(", "); printf("%s",$2);}'`
       if test "$kvmerr" != "" ; then
@@ -1817,7 +1821,6 @@ case "$target_cpu" in
     fi
     if test "$kvm" = "yes" ; then
       echo "CONFIG_KVM=yes" >> $config_mak
-      echo "KVM_CFLAGS=$kvm_cflags" >> $config_mak
       echo "#define CONFIG_KVM 1" >> $config_h
     fi
     if test "$xen" = "yes" -a "$target_softmmu" = "yes";
@@ -1838,7 +1841,6 @@ case "$target_cpu" in
     fi
     if test "$kvm" = "yes" ; then
       echo "CONFIG_KVM=yes" >> $config_mak
-      echo "KVM_CFLAGS=$kvm_cflags" >> $config_mak
       echo "#define CONFIG_KVM 1" >> $config_h
     fi
     if test "$xen" = "yes" -a "$target_softmmu" = "yes"
@@ -1906,7 +1908,6 @@ case "$target_cpu" in
     echo "#define TARGET_PPCEMB 1" >> $config_h
     if test "$kvm" = "yes" ; then
       echo "CONFIG_KVM=yes" >> $config_mak
-      echo "KVM_CFLAGS=$kvm_cflags" >> $config_mak
       echo "#define CONFIG_KVM 1" >> $config_h
     fi
     gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml power-spe.xml"
diff --git a/linux/Makefile b/linux/Makefile
new file mode 100644
index 0000000..68a5844
--- /dev/null
+++ b/linux/Makefile
@@ -0,0 +1,108 @@
+KERNELDIR ?= /lib/modules/$(shell uname -r)/build
+
+# Basic types/annotations that Linux headers use
+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
+
+# 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
+
+# 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
+
+sync: sync-kvm sync-virtio sync-tun sync-timer sync-usb sync-disk sync-pport
+
+sync-core: $(CORE_HDRS)
+
+sync-kvm: sync-core $(KVM_HDRS)
+
+sync-virtio: sync-core $(VIRTIO_HDRS)
+
+sync-tun: sync-core $(TUN_HDRS)
+
+sync-timer: sync-core $(TIMER_HDRS)
+
+sync-usb: sync-core $(USB_HDRS)
+
+sync-disk: sync-core $(DISK_HDRS)
+
+sync-pport: sync-core $(PPORT_HDRS)
+
+clean:
+	@$(RM) -r linux asm-x86 asm-powerpc asm-generic asm-sparc asm-arm \
+	          asm-parisc
+
+linux/%: $(KERNELDIR)/include/linux/%
+	@mkdir -p $(shell dirname $@)
+	@echo "  IMPORT    $@"
+	@sed -f fixup.sed $< > $@
+
+asm-generic/%: $(KERNELDIR)/include/asm-generic/%
+	@mkdir -p $(shell dirname $@)
+	@echo "  IMPORT    $@"
+	@sed -f fixup.sed $< > $@
+
+asm-x86/%: $(KERNELDIR)/arch/x86/include/asm/%
+	@mkdir -p $(shell dirname $@)
+	@echo "  IMPORT    $@"
+	@sed -f fixup.sed $< > $@
+
+asm-powerpc/%: $(KERNELDIR)/arch/powerpc/include/asm/%
+	@mkdir -p $(shell dirname $@)
+	@echo "  IMPORT    $@"
+	@sed -f fixup.sed $< > $@
+
+asm-sparc/%: $(KERNELDIR)/arch/sparc/include/asm/%
+	@mkdir -p $(shell dirname $@)
+	@echo "  IMPORT    $@"
+	@sed -f fixup.sed $< > $@
+
+asm-arm/%: $(KERNELDIR)/arch/arm/include/asm/%
+	@mkdir -p $(shell dirname $@)
+	@echo "  IMPORT    $@"
+	@sed -f fixup.sed $< > $@
+
+asm-parisc/%: $(KERNELDIR)/arch/parisc/include/asm/%
+	@mkdir -p $(shell dirname $@)
+	@echo "  IMPORT    $@"
+	@sed -f fixup.sed $< > $@
+
+.PHONY: clean
diff --git a/linux/README b/linux/README
new file mode 100644
index 0000000..e29d39b
--- /dev/null
+++ b/linux/README
@@ -0,0 +1,19 @@
+This directory contains a snapshot of Linux kernel headers.  The included
+Makefile was used to import these headers into QEMU.
+
+This process is intended for use by the QEMU maintainers.  It is not intended
+to work against arbitrary kernel versions nor is the intention for end-users to
+use this to update the included headers.
+
+If a contributor needs a newer kernel header for a feature implemented
+by a particular patch, please run the appropriate make sync-* command and
+send the results of that command as a separate patch.  Also make sure to update
+this file to reflect the kernel version used.
+
+While it is okay for development versions of QEMU to contain headers from
+non-release versions of the Linux kernel, any official release of QEMU must use
+headers from a released version of the Linux kernel to ensure ABI compatibility.
+
+Kernel versions used:
+
+git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v2.6.30-rc4
diff --git a/linux/fixup.sed b/linux/fixup.sed
new file mode 100644
index 0000000..c0ad124
--- /dev/null
+++ b/linux/fixup.sed
@@ -0,0 +1,19 @@
+# Header file fix ups.  This is tailored for importing the kvm linux headers
+
+# Expand asm/ includes to avoid having to do symlink trickery
+s:^#include <asm/\(.*\)>:                              \
+#if defined(__x86_64__) || defined(__i386__)            \
+#include "asm-x86/\1"                                   \
+#elif defined(__powerpc__)                              \
+#include "asm-powerpc/\1"                               \
+#elif defined(__sparc__)                                \
+#include "asm-sparc/\1"                                 \
+#elif defined(__hppa__)                                 \
+#include "asm-parisc/\1"                                \
+#elif defined(__arm__)                                  \
+#include "asm-arm/\1"                                   \
+#else                                                   \
+#error Using Linux headers on unknown architecture      \
+#endif                                                  \
+:g
+s:^#include <linux/\(.*\)>:#include "linux/\1":g
diff --git a/usb-linux.c b/usb-linux.c
index 70d7a1c..1392579 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -39,7 +39,6 @@
 #include <signal.h>
 
 #include <linux/usbdevice_fs.h>
-#include <linux/version.h>
 #include "hw/usb.h"
 
 /* We redefine it to avoid version problems */
-- 
1.6.0.6

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

[Stefan Weil]

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

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

[Edgar E. Iglesias]

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.

Cheers

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

[Anthony Liguori]

Edgar E. Iglesias wrote:
> I don't feel very strongly about it but my gut feeling tells me we
> shouldn't be doing this.
>   

We have to.  It's not just KVM, it's virtio, tun/tap, and as we add more 
things to the Linux kernel to support QEMU, it'll just grow larger.

This is how applications are supposed to use kernel headers.  It's 
unpleasant, but that's just the way Linux is today.

Regards,

Anthony Liguori

> Cheers
>   

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

[Edgar E. Iglesias]

On Mon, May 04, 2009 at 08:15:58AM -0500, Anthony Liguori wrote:
> Edgar E. Iglesias wrote:
>> I don't feel very strongly about it but my gut feeling tells me we
>> shouldn't be doing this.
>>   
>
> We have to.  It's not just KVM, it's virtio, tun/tap, and as we add more 
> things to the Linux kernel to support QEMU, it'll just grow larger.

I'm not sure we have too. QEMU users that build from source can IMO
be expected to update kernel headers if required and if our configure
is explicit about it. "You didn't get feature x because you have an
old kernel or old kernel headers" kind of warning.

Another alternative is to provide an option so users can specify
where to find alternative kernel-headers. IIRC other I've seen
this approach in several other projects.

I agree with you that the compat ifdefs are annoying though...

> This is how applications are supposed to use kernel headers.  It's 
> unpleasant, but that's just the way Linux is today.

Do you mean that all apps using linux header files should bring those
in?

Cheers

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

[Anthony Liguori]

Stefan Weil wrote:
> Anthony Liguori schrieb:
>   
>
> 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.
>   

We can not just rely on everyone who uses QEMU to use the latest version 
of Debian...

The fact is, linux-libc-dev is *not* meant for applications to use as 
the official kernel ABI.  We shouldn't depend on it.

Regards,

Anthony Liguori

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

[Avi Kivity]

Anthony Liguori wrote:
> Stefan Weil wrote:
>> Anthony Liguori schrieb:
>>  
>> 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.
>>   
>
> We can not just rely on everyone who uses QEMU to use the latest 
> version of Debian...
>
> The fact is, linux-libc-dev is *not* meant for applications to use as 
> the official kernel ABI.  We shouldn't depend on it.

At least on Fedora, kernel-headers is.  It is installed in 
/usr/include/linux and is synced (sorta) to the installed kernel.

Carrying a subset of kernel headers is a bit too much, IMO.

kvm is a special case since it is available externally.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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

[Anthony Liguori]

Avi Kivity wrote:
> At least on Fedora, kernel-headers is.  It is installed in 
> /usr/include/linux and is synced (sorta) to the installed kernel.

It's not the case with Ubuntu.

> Carrying a subset of kernel headers is a bit too much, IMO.

Carrying virtio, kvm, and if_tun would be sufficient IMO.  I think 
depending on /usr/include/linux is okay for kvm and if_tun, but virtio 
needs to be buildable without /usr/include/linux.

Regards,

Anthony Liguori

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

[Christoph Hellwig]

On Mon, May 04, 2009 at 08:13:16AM -0500, Anthony Liguori wrote:
> The fact is, linux-libc-dev is *not* meant for applications to use as 
> the official kernel ABI.  We shouldn't depend on it.

Umm, it is.  That's exactly the reason what it is for.  Note that the
name of the package varies depending on the distro, but those headers
in /usr/include/linux/ are the ABI for features not shimed by libc.

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

[Lennart Sorensen]

On Mon, May 04, 2009 at 08:13:16AM -0500, Anthony Liguori wrote:
> We can not just rely on everyone who uses QEMU to use the latest version  
> of Debian...
>
> The fact is, linux-libc-dev is *not* meant for applications to use as  
> the official kernel ABI.  We shouldn't depend on it.

Actually I think that is exactly what it is intended to be and exactly
what you should do.

-- 
Len Sorensen

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

[Avi Kivity]

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.

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

[Paul Brook]

> I think we need to use the output of 'make headers-install', which
> removes things like __user and CONFIG_*.

Yes. Assuming we do decide to import a set of headers, they should definitely 
be the sanitised version created by make headers-install.

Paul

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

[Anthony Liguori]

Avi Kivity wrote:
>> <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_*.

I was thinking about that as a possibility too.  We still need the same 
basic infrastructure though.

Regards,

Anthony Liguori

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

[Avi Kivity]

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.

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

[Mark McLoughlin]

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.

Cheers,
Mark.

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

[Arnd Bergmann]

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 <><

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

[Anthony Liguori]

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 <><
>   

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

[Avi Kivity]

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.

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

[Anthony Liguori]

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

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

[Avi Kivity]

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.

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

[Arnd Bergmann]

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 <><

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

[Anthony Liguori]

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

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

[Avi Kivity]

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.

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

[Christoph Hellwig]

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.

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

[Arnd Bergmann]

On Monday 04 May 2009, Anthony Liguori wrote:
> Arnd Bergmann wrote:
> >
> > 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.

Right. But I don't think we will see new cases like this in the future
and we can work around the existing breakage by doing things like

#undef __user
#define __user
#include <linux/usbdevice_fs.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).

There is a big difference between the kvm headers and the virtio headers
then. For virtio, it will be easy to automatically change them not to
rely on the core headers, because the only thing they use from there
are really the integer types (__u32 and others). We can either define them
in qemu, or replace them with C99 inttypes using sed.

The kvm headers are much harder, because they actually rely on architecture
specific stuff like ioctl.h, but then again, I don't think that you
want to provide kvm.h on Win32, unless you are cross-compiling for a Linux
host (implying that you already have the full set of headers).

> > 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.

Ok, it makes more sense now.

	Arnd <><