qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost


From: Scott Wood
Subject: Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
Date: Tue, 3 May 2011 12:57:18 -0500

On Tue, 3 May 2011 19:32:00 +0200
"Edgar E. Iglesias" <address@hidden> wrote:

> On Tue, May 03, 2011 at 08:13:04PM +0300, Avi Kivity wrote:
> > On 05/03/2011 08:09 PM, Jan Kiszka wrote:
> > > >
> > > >  Reluctant ack.
> > >
> > > What downsides do you see?
> > 
> > The usual "it shouldn't be this way".  Every other package (including, I 
> > think, glibc) uses the sanitized system headers.  Except for kvm-kmod, 
> > the system headers are always available.

They're usually available, but often not recent.  This turns qemu's kvm
bits into an error-prone ifdef soup, and still requires the user to extract
and point to their own set of sanitized kernel headers if they want the
newer features (even if they don't have any other need to build a kernel).

By including the headers in qemu, we can ensure that the headers are in sync
with qemu's expectations.

As for glibc, that's less likely to be built by an end-user, and more
likely to be built by whoever was responsible for generating the system's
sanitized headers.  Even so, it probably relies on a bunch of autoconf gunk
to deal with various versions of the headers.  And glibc doesn't have the
benefit of dynamic capability testing of the APIs -- it may be relying on
the headers it builds against not being newer than the kernel it runs on.

> I agree, it doesn't feel quite right to bring in the headers. I don't have
> any alternative suggestions (besides better HOWTOs/Documentation) though. 

If you try to use the non-sanitized kernel headers, you'll get this warning
from linux/types.h:

#warning "Attempt to use kernel headers from user space, see 
http://kernelnewbies.org/KernelHeaders";

At that URL, you'll find this:

  If you are distributing a user space program that depends on a specific
  version of some kernel headers, e.g.  because your program runs only on
  patched or very recent kernels, you cannot rely on the headers in
  /usr/include.  You also cannot use the header files from
  /usr/src/linux/include or /lib/modules/*/build/include/ because they have
  not been prepared for inclusion in user space.  The kernel should warn
  you about this if you try it and point you to this Wiki page.  The
  correct way to address this problem is to isolate the specific interfaces
  that you need, e.g.  a single header file that is patched in a new kernel
  providing the ioctl numbers for a character device used by your program. 
  In your own program, add a copy of that source file, with a notice that
  it should be kept in sync with new kernel versions.
        
-Scott




reply via email to

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