On Tue, 3 May 2011 19:32:00 +0200 "Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
