qemu-devel
[Top][All Lists]
Advanced

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

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


From: Arnd Bergmann
Subject: [Qemu-devel] Re: [RFC] Bring in all the Linux headers we depend on in QEMU
Date: Mon, 4 May 2009 16:18:27 +0200
User-agent: KMail/1.9.9

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




reply via email to

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