From: Scott Wood <scottwood@freescale.com>
To: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, kvm <kvm@vger.kernel.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
Alexander Graf <agraf@suse.de>, Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] Import Linux headers for KVM and vhost
Date: Tue, 3 May 2011 12:57:18 -0500 [thread overview]
Message-ID: <20110503125718.3e95f9ba@schlenkerla.am.freescale.net> (raw)
In-Reply-To: <20110503173200.GA30864@laped.lan>
On Tue, 3 May 2011 19:32:00 +0200
"Edgar E. Iglesias" <edgar.iglesias@gmail.com> 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
next prev parent reply other threads:[~2011-05-03 17:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-03 14:05 [Qemu-devel] [RFC][PATCH] Import Linux headers for KVM and vhost Jan Kiszka
2011-05-03 15:12 ` Christoph Hellwig
2011-05-03 15:32 ` Jan Kiszka
2011-05-03 15:41 ` Arnd Bergmann
2011-05-03 16:48 ` [Qemu-devel] [PATCH v2] " Jan Kiszka
2011-05-03 16:55 ` Avi Kivity
2011-05-03 17:09 ` Jan Kiszka
2011-05-03 17:13 ` Avi Kivity
2011-05-03 17:32 ` Edgar E. Iglesias
2011-05-03 17:39 ` Jan Kiszka
2011-05-03 17:57 ` Scott Wood [this message]
2011-05-03 19:26 ` Arnd Bergmann
2011-05-03 17:30 ` Peter Maydell
2011-05-03 17:42 ` Jan Kiszka
2011-05-03 17:45 ` Anthony Liguori
2011-05-03 17:55 ` Jan Kiszka
2011-05-03 17:59 ` Anthony Liguori
2011-05-03 21:37 ` Michael S. Tsirkin
2011-05-04 8:55 ` Jan Kiszka
2011-05-09 3:24 ` Rusty Russell
2011-05-03 20:22 ` Peter Maydell
2011-05-04 10:28 ` Jan Kiszka
2011-05-04 17:58 ` Andreas Färber
2011-05-04 18:01 ` Jan Kiszka
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=20110503125718.3e95f9ba@schlenkerla.am.freescale.net \
--to=scottwood@freescale.com \
--cc=agraf@suse.de \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=edgar.iglesias@gmail.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--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;
as well as URLs for NNTP newsgroup(s).