Import Linux headers for KVM and vhost
Subsystems (4)
RFC PATCH 1/1 Import Linux headers for KVM and vhost
This helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine.
Header upstate is triggered via 'make update-linux-headers', optionally specifying a kernel directory as source via 'LINUX='.
---
I'm sure this is not yet perfect from technical POV (e.g. the patch to Makefile.target looks like a hack to me, better ideas welcome), therefore RFC and no SOB. But it should demonstrate the plan. The workflow for adding a new KVM feature support would be first a 'make update-linux-header LINUX=/my/local/linux' + git commit, and then the commit of the kvm, vhost, whatever changes.
A patch to actually add the result of the header update would be posted separately. Same for the now possible massive cleanups of kvm sources.
Makefile | 17 +++++++ Makefile.target | 2 +- configure | 127 ++++++++----------------------------------------------- 3 files changed, 36 insertions(+), 110 deletions(-)
Makefile +17 -0
@@ -341,3 +341,20 @@ tarbin: # Include automatically generated dependency files -include $(wildcard *.d audio/*.d slirp/*.d block/*.d net/*.d ui/*.d) + +update-linux-headers: + for arch in x86 powerpc s390; do \ + $(MAKE) -C $(LINUX) INSTALL_HDR_PATH=`pwd`/.tmp-hdrs SRCARCH="$$arch" headers_install; \ + rm -rf $(SRC_PATH)/include/asm-"$$arch"/*; \ + for header in kvm.h kvm_para.h; do \ + cp .tmp-hdrs/include/asm/$$header $(SRC_PATH)/include/asm-"$$arch"; \ + done; \ + if test $$arch == x86; then \ + cp .tmp-hdrs/include/asm/hyperv.h $(SRC_PATH)/include/asm-x86; \ + fi \ + done + rm -rf $(SRC_PATH)/include/linux/* + for header in kvm.h kvm_para.h vhost.h virtio_config.h virtio_ring.h; do \ + cp .tmp-hdrs/include/linux/$$header $(SRC_PATH)/include/linux; \ + done + rm -rf .tmp-hdrs
Makefile.target +1 -1
@@ -14,7 +14,7 @@ endif TARGET_PATH=$(SRC_PATH)/target-$(TARGET_BASE_ARCH) $(call set-vpath, $(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw) -QEMU_CFLAGS+= -I.. -I$(TARGET_PATH) -DNEED_CPU_H +QEMU_CFLAGS+= -I.. -I../include -I$(TARGET_PATH) -DNEED_CPU_H include $(SRC_PATH)/Makefile.objs
configure +18 -109
157 lines not on this page · raw message
Signature · 1 line
1.7.1
Quoted 6 lines · Jan Kiszka
This helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine.
Header upstate is triggered via 'make update-linux-headers', optionally specifying a kernel directory as source via 'LINUX='.
Why not make it a shell scripts? It's not like it's part of the build system. I also think the source tree argument should be mandatory instead of grabbing random headers.
Quoted 11 lines · Christoph Hellwig
Quoted 6 lines · Jan Kiszka
This helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine.
Header upstate is triggered via 'make update-linux-headers', optionally specifying a kernel directory as source via 'LINUX='.
Why not make it a shell scripts? It's not like it's part of the build system. I also think the source tree argument should be mandatory instead of grabbing random headers.
Yes, makes sense. I just adopted the kvm-kmod style here which I'm used to.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 16 lines · Jan Kiszka
This helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine.
Header upstate is triggered via 'make update-linux-headers', optionally specifying a kernel directory as source via 'LINUX='.
---
I'm sure this is not yet perfect from technical POV (e.g. the patch to Makefile.target looks like a hack to me, better ideas welcome), therefore RFC and no SOB. But it should demonstrate the plan. The workflow for adding a new KVM feature support would be first a 'make update-linux-header LINUX=/my/local/linux' + git commit, and then the commit of the kvm, vhost, whatever changes.
Quoted 4 lines
Makefile | 17 +++++++ Makefile.target | 2 +- configure | 127 ++++++++----------------------------------------------- 3 files changed, 36 insertions(+), 110 deletions(-)
Very nice!
The old way to poke into the kernel internals was really annoying and confusing.
Arnd
PATCH v2 1/1 Import Linux headers for KVM and vhost
In reply to Jan KiszkaThis helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine.
Header upstate is triggered via
scripts/update-linux-headers.sh LINUX_PATH
from the top-level QEMU source directory.
Consequently, the patch removes and build-time checks for kvm and vhost in configure, and also the --kerneldir switch. Kernel headers are supposed to be provided by QEMU only.
Kernel headers were automatically imported from current kvm.git, 93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception. Some are explicitly GPLv2 - at least for QEMU that's fine in any case. Others are "BSD" which shall to be considered a compatible variant according to Rusty.
---
v2:
- push update into a script
- made kernel path mandatory
- included kernel header (may break the build otherwise)
- removed obsolete --kerneldir configure switch
Makefile.target | 2 +- configure | 131 +------ include/asm-powerpc/kvm.h | 91 +++++ include/asm-powerpc/kvm_para.h | 53 +++ include/asm-s390/kvm.h | 44 +++ include/asm-s390/kvm_para.h | 17 + include/asm-x86/hyperv.h | 193 ++++++++++ include/asm-x86/kvm.h | 324 ++++++++++++++++ include/asm-x86/kvm_para.h | 79 ++++ include/linux/kvm.h | 803 +++++++++++++++++++++++++++++++++++++++ include/linux/kvm_para.h | 29 ++ include/linux/vhost.h | 130 +++++++ include/linux/virtio_config.h | 31 ++ include/linux/virtio_ring.h | 113 ++++++ scripts/update-linux-headers.sh | 47 +++ 15 files changed, 1973 insertions(+), 114 deletions(-) create mode 100644 include/asm-powerpc/kvm.h create mode 100644 include/asm-powerpc/kvm_para.h create mode 100644 include/asm-s390/kvm.h create mode 100644 include/asm-s390/kvm_para.h create mode 100644 include/asm-x86/hyperv.h create mode 100644 include/asm-x86/kvm.h create mode 100644 include/asm-x86/kvm_para.h create mode 100644 include/linux/kvm.h create mode 100644 include/linux/kvm_para.h create mode 100644 include/linux/vhost.h create mode 100644 include/linux/virtio_config.h create mode 100644 include/linux/virtio_ring.h create mode 100755 scripts/update-linux-headers.sh
Makefile.target +1 -1
@@ -14,7 +14,7 @@ endif TARGET_PATH=$(SRC_PATH)/target-$(TARGET_BASE_ARCH) $(call set-vpath, $(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw) -QEMU_CFLAGS+= -I.. -I$(TARGET_PATH) -DNEED_CPU_H +QEMU_CFLAGS+= -I.. -I../include -I$(TARGET_PATH) -DNEED_CPU_H include $(SRC_PATH)/Makefile.objs
configure +18 -113
179 lines not on this page · raw message
include/asm-powerpc/kvm.h new file +91 -0
91 lines not on this page · raw message
include/asm-powerpc/kvm_para.h new file +53 -0
53 lines not on this page · raw message
include/asm-s390/kvm.h new file +44 -0
44 lines not on this page · raw message
include/asm-s390/kvm_para.h new file +17 -0
@@ -0,0 +1,17 @@ +/* +* asm-s390/kvm_para.h - definition for paravirtual devices on s390 +* +* Copyright IBM Corp. 2008 +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License (version 2 only) +* as published by the Free Software Foundation. +* +* Author(s): Christian Borntraeger <[email protected]> +*/ + +#ifndef __S390_KVM_PARA_H +#define __S390_KVM_PARA_H + + +#endif /* __S390_KVM_PARA_H */
include/asm-x86/hyperv.h new file +193 -0
193 lines not on this page · raw message
include/asm-x86/kvm.h new file +324 -0
324 lines not on this page · raw message
include/asm-x86/kvm_para.h new file +79 -0
79 lines not on this page · raw message
include/linux/kvm.h new file +803 -0
803 lines not on this page · raw message
include/linux/kvm_para.h new file +29 -0
@@ -0,0 +1,29 @@ +#ifndef __LINUX_KVM_PARA_H +#define __LINUX_KVM_PARA_H + +/* +* This header file provides a method for making a hypercall to the host +* Architectures should define: +* - kvm_hypercall0, kvm_hypercall1... +* - kvm_arch_para_features +* - kvm_para_available +*/ + +/* Return values for hypercalls */ +#define KVM_ENOSYS 1000 +#define KVM_EFAULT EFAULT +#define KVM_E2BIG E2BIG +#define KVM_EPERM EPERM + +#define KVM_HC_VAPIC_POLL_IRQ 1 +#define KVM_HC_MMU_OP 2 +#define KVM_HC_FEATURES 3 +#define KVM_HC_PPC_MAP_MAGIC_PAGE 4 + +/* +* hypercalls use architecture specific +*/ +#include <asm/kvm_para.h> + +#endif /* __LINUX_KVM_PARA_H */ +
include/linux/vhost.h new file +130 -0
130 lines not on this page · raw message
include/linux/virtio_config.h new file +31 -0
@@ -0,0 +1,31 @@ +#ifndef _LINUX_VIRTIO_CONFIG_H +#define _LINUX_VIRTIO_CONFIG_H +/* This header, excluding the #ifdef __KERNEL__ part, is BSD licensed so +* anyone can use the definitions to implement compatible drivers/servers. */ + +/* Virtio devices use a standardized configuration space to define their +* features and pass configuration information, but each implementation can +* store and access that space differently. */ +#include <linux/types.h> + +/* Status byte for guest to report progress, and synchronize features. */ +/* We have seen device and processed generic fields (VIRTIO_CONFIG_F_VIRTIO) */ +#define VIRTIO_CONFIG_S_ACKNOWLEDGE 1 +/* We have found a driver for the device. */ +#define VIRTIO_CONFIG_S_DRIVER 2 +/* Driver has used its parts of the config, and is happy */ +#define VIRTIO_CONFIG_S_DRIVER_OK 4 +/* We've given up on this device. */ +#define VIRTIO_CONFIG_S_FAILED 0x80 + +/* Some virtio feature bits (currently bits 28 through 31) are reserved for the +* transport being used (eg. virtio_ring), the rest are per-device feature +* bits. */ +#define VIRTIO_TRANSPORT_F_START 28 +#define VIRTIO_TRANSPORT_F_END 32 + +/* Do we get callbacks when the ring is completely used, even if we've +* suppressed them? */ +#define VIRTIO_F_NOTIFY_ON_EMPTY 24 + +#endif /* _LINUX_VIRTIO_CONFIG_H */
include/linux/virtio_ring.h new file +113 -0
113 lines not on this page · raw message
scripts/update-linux-headers.sh new file +47 -0
47 lines not on this page · raw message
Signature · 1 line
1.7.1
Quoted 14 lines · Jan Kiszka
This helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine.
Header upstate is triggered via
scripts/update-linux-headers.shLINUX_PATHfrom the top-level QEMU source directory.
Consequently, the patch removes and build-time checks for kvm and vhost in configure, and also the --kerneldir switch. Kernel headers are supposed to be provided by QEMU only.
Quoted 5 lines
Kernel headers were automatically imported from current kvm.git,
93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception. Some are explicitly GPLv2 - at least for QEMU that's fine in any case. Others are "BSD" which shall to be considered a compatible variant according to Rusty.
Reluctant ack.
(though for commit log cleanliness, the scripts and the headers should be in separate commits)
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 15 lines · Avi Kivity
Quoted 14 lines · Jan Kiszka
This helps reducing our build-time checks for feature support in the available Linux kernel headers. And it helps users that do not have sufficiently recent headers installed on their build machine.
Header upstate is triggered via
scripts/update-linux-headers.shLINUX_PATHfrom the top-level QEMU source directory.
Consequently, the patch removes and build-time checks for kvm and vhost in configure, and also the --kerneldir switch. Kernel headers are supposed to be provided by QEMU only.
Quoted 7 lines
Quoted 5 lines
Kernel headers were automatically imported from current kvm.git,
93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception. Some are explicitly GPLv2 - at least for QEMU that's fine in any case. Others are "BSD" which shall to be considered a compatible variant according to Rusty.Reluctant ack.
What downsides do you see?
Quoted 4 lines
(though for commit log cleanliness, the scripts and the headers should be in separate commits)
I'll split up in thread parts: script, headers, build system changes.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 4 lines · Jan Kiszka
Quoted 2 lines
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.
But if it's causing people pain, I don't want to insist.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 9 lines · Avi Kivity
Quoted 4 lines · Jan Kiszka
Quoted 2 lines
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.
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.
Cheers
Quoted 5 lines · Edgar E. Iglesias
Quoted 4 lines · Avi Kivity
Quoted 3 lines · Jan Kiszka
Quoted 2 lines
Reluctant ack.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
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.
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.
Again, the downside of the current approach are:
- outdated distro headers silently disable features during build time (happened to me with vhost e.g.)
- build breakages against older kernels / headers are pre-programmed as hardly anyone tests all the possible combinations
- tons of #ifdef in the code + configure checks to catch the possible combinations
Also note that [1] recommends this approach as well. I'm not aware of good examples, but I would be fairly surprised if we were the first to do this.
Jan
[1] http://kernelnewbies.org/KernelHeaders
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 10 lines · On Tue, 3 May 2011 19:32:00 +0200 "Edgar E. Iglesias"…
Quoted 9 lines · Avi Kivity
Quoted 4 lines · Jan Kiszka
Quoted 2 lines
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.
Quoted 2 lines
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
Quoted 8 lines · On Tuesday 03 May 2011 19:57:18 Scott Wood wrote:
Quoted 2 lines
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"
You're welcome ;-)
I tried to make the recommended approach as clear as I could with the #warning and the wiki page. If there is anything still unclear about how it should be done, please make suggestions for improving the wiki text.
Arnd
Quoted 3 lines · Jan Kiszka
Kernel headers were automatically imported from current kvm.git,
93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception.
Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me...
-- PMM
Quoted 9 lines · Peter Maydell
Quoted 3 lines · Jan Kiszka
Kernel headers were automatically imported from current kvm.git,
93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception.Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me...
I will discuss this internally again (with those people running the result through FOSSology sooner or later anyway).
What about auto-importing the Linux top-level license file as well and putting it under include/? That would replicate what you find in Linux today and should at least maintain the level of pain, not increase it.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 9 lines · Peter Maydell
Quoted 3 lines · Jan Kiszka
Kernel headers were automatically imported from current kvm.git,
93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception.Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me...
Which are the headers in question?
Regards,
Anthony Liguori
Quoted 2 lines
-- PMM
Quoted 6 lines · Anthony Liguori
Quoted 5 lines · Peter Maydell
Quoted 3 lines · Jan Kiszka
Kernel headers were automatically imported from current kvm.git,
93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception.
Quoted 6 lines
Quoted 4 lines
Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me...
Which are the headers in question?
include/asm-powerpc: explicit GPLv2include/asm-s390: explicit GPLv2include/asm/x86: no license mentionedinclude/linux/kvm*: no license mentionedinclude/linux/vhost: no license mentionedinclude/linux/virtio*: "BSB"
The last group already popped up here during a license clearing of the kernel. I contacted Rusty on them and got the answer "Standard 3 clause.
The 4 clause is incompatible with the GPL." That was OK for our
purposes, but I nevertheless asked Rusty to push a clarifying sentence to the kernel - unfortunately this did not happen so far.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 12 lines · Jan Kiszka
Quoted 11 lines · Anthony Liguori
Quoted 9 lines · Peter Maydell
Quoted 3 lines · Jan Kiszka
Kernel headers were automatically imported from current kvm.git,
93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception.Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me...
Quoted 7 lines
Quoted 1 line
Which are the headers in question?
include/asm-powerpc: explicit GPLv2include/asm-s390: explicit GPLv2include/asm/x86: no license mentionedinclude/linux/kvm*: no license mentionedinclude/linux/vhost: no license mentioned
Michael/Avi, can ya'll add copyrights/licenses as appropriate?
Quoted 7 lines
include/linux/virtio*: "BSB"The last group already popped up here during a license clearing of the kernel. I contacted Rusty on them and got the answer "Standard 3 clause.
The 4 clause is incompatible with the GPL." That was OK for our
purposes, but I nevertheless asked Rusty to push a clarifying sentence to the kernel - unfortunately this did not happen so far.
Rusty, do you want to put together a patch with the full license or should I?
Regards,
Anthony Liguori
Quoted 3 lines
Jan
Michael S. Tsirkin
maintainerQuoted 15 lines · Anthony Liguori
Quoted 14 lines · Jan Kiszka
Quoted 12 lines · Anthony Liguori
Quoted 9 lines · Peter Maydell
Quoted 3 lines · Jan Kiszka
Kernel headers were automatically imported from current kvm.git,
93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception.Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me...
Which are the headers in question?
Quoted 7 lines
Quoted 5 lines
include/asm-powerpc: explicit GPLv2include/asm-s390: explicit GPLv2include/asm/x86: no license mentionedinclude/linux/kvm*: no license mentionedinclude/linux/vhost: no license mentionedMichael/Avi, can ya'll add copyrights/licenses as appropriate?
All kernel is GPLv2 with userspace exceptions. The explicit GPLv2 licenses are likely uninitentional. So I don't really believe licenses are applicable in headers, we see how this creates confusion.
Just place the kernel COPYING file into the include directory?
Quoted 18 lines
Quoted 7 lines
include/linux/virtio*: "BSB"The last group already popped up here during a license clearing of the kernel. I contacted Rusty on them and got the answer "Standard 3 clause.
The 4 clause is incompatible with the GPL." That was OK for our
purposes, but I nevertheless asked Rusty to push a clarifying sentence to the kernel - unfortunately this did not happen so far.Rusty, do you want to put together a patch with the full license or should I?
Regards,
Anthony Liguori
Quoted 3 lines
Jan
Quoted 22 lines · Michael S. Tsirkin
Quoted 21 lines · Anthony Liguori
Quoted 19 lines · Jan Kiszka
Quoted 6 lines · Anthony Liguori
Quoted 5 lines · Peter Maydell
Quoted 3 lines · Jan Kiszka
Kernel headers were automatically imported from current kvm.git,
93c016c8c4. Some are not covered by any license and can be considered GPLv2 with user space exception.Quoted 6 lines
Quoted 4 lines
Hmm. Can't we just get whoever owns those files to apply a suitable copyright and license header to them? Committing files to qemu.git which don't have a clear (and clearly stated) copyright/license seems like a bad plan to me...
Which are the headers in question?
include/asm-powerpc: explicit GPLv2include/asm-s390: explicit GPLv2include/asm/x86: no license mentionedinclude/linux/kvm*: no license mentionedinclude/linux/vhost: no license mentioned
Quoted 3 lines
Quoted 1 line
Michael/Avi, can ya'll add copyrights/licenses as appropriate?
All kernel is GPLv2 with userspace exceptions.
That's not that simple. There is a lot of dual licensing, and the virtio header are BSD 3-clause as we know.
Quoted 3 lines
The explicit GPLv2
licenses are likely uninitentional. So I don't really believe licenses are applicable in headers, we see how this creates confusion.
Well, if you state that your work on headers is not copyrighted and can thus be used under any license, that's OK. But you can't speak for others. And we should better avoid that such discussions escalate to any legal authorities. :)
Quoted 2 lines
Just place the kernel COPYING file into the include directory?
That is one option I've already built into my latest patch version, even for the case we come to a more explicit solution.
But one point of all this is to make life easier for those poor people who have check a qemu source package before redistribution for included licenses. The clearer the terms are expressed, the easier these "unproductive" processes become. You can't imagine what activities that vague "BSD" license of the virtio headers triggered here...
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 5 lines · Jan Kiszka
But one point of all this is to make life easier for those poor people who have check a qemu source package before redistribution for included licenses. The clearer the terms are expressed, the easier these "unproductive" processes become. You can't imagine what activities that vague "BSD" license of the virtio headers triggered here...
Yes, so much so that I have been known to recommend that reimplementors go for the headers out of the virtio spec file, which are definitively uncontaminated.
However, I have prepared a patch, will send now...
Thanks for prod,
Rusty.
scripts/update-linux-headers.sh line 1
Quoted 3 lines · Jan Kiszka
+++
b/scripts/update-linux-headers.shscripts/update-linux-headers.sh new file +1
-0@@ -0,0 +1,47 @@ +#!/bin/sh
No -e ?
scripts/update-linux-headers.sh line 43
Quoted 1 line
scripts/update-linux-headers.sh new file +1
-0+rm -rf $output/include/linux/*
Given that updating the kernel headers will blow away large subsets of include/ like this, maybe we should use a less generic name than "include", so it's clear that it's just a set of automatically maintained and updated files, rather than a good place to put random QEMU header files?
kernel-headers/ seems like an obvious choice.
Is it worth having a README in the directory saying "don't edit these, they are copies of the kernel headers, they can be updated with <whatever>", or is that unnecessary?
-- PMM
Quoted 15 lines · Peter Maydell
scripts/update-linux-headers.sh line 1
Quoted 3 lines · Jan Kiszka
+++
b/scripts/update-linux-headers.shscripts/update-linux-headers.sh new file +1
-0@@ -0,0 +1,47 @@ +#!/bin/shNo -e ?
scripts/update-linux-headers.sh line 43
Quoted 1 line
scripts/update-linux-headers.sh new file +1
-0+rm -rf $output/include/linux/*Given that updating the kernel headers will blow away large subsets of
include/like this, maybe we should use a less generic name than "include", so it's clear that it's just a set of automatically maintained and updated files, rather than a good place to put random QEMU header files?
Quoted 6 lines
kernel-headers/ seems like an obvious choice.
Is it worth having a README in the directory saying "don't edit these, they are copies of the kernel headers, they can be updated with <whatever>", or is that unnecessary?
No, these suggestion all make sense. I've incorporated them.
Thanks,
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Am 04.05.2011 um 12:28 schrieb Jan Kiszka:
Quoted 12 lines · Peter Maydell
Quoted 11 lines · Jan Kiszka
Quoted 3 lines
+++
b/scripts/update-linux-headers.sh+rm -rf $output/include/linux/*
Given that updating the kernel headers will blow away large subsets of
include/like this, maybe we should use a less generic name than "include", so it's clear that it's just a set of automatically maintained and updated files, rather than a good place to put random QEMU header files?
Quoted 3 lines
Quoted 1 line
kernel-headers/ seems like an obvious choice.
[...] these suggestion all make sense. I've incorporated them.
If we're talking about a new directory inside the QEMU tree, mind to name it linux-headers or so? There are other kernels besides The One. :)
Andreas
Quoted 14 lines · Andreas Färber
Am 04.05.2011 um 12:28 schrieb Jan Kiszka:
Quoted 12 lines · Peter Maydell
Quoted 11 lines · Jan Kiszka
Quoted 3 lines
+++
b/scripts/update-linux-headers.sh+rm -rf $output/include/linux/*
Given that updating the kernel headers will blow away large subsets of
include/like this, maybe we should use a less generic name than "include", so it's clear that it's just a set of automatically maintained and updated files, rather than a good place to put random QEMU header files?
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
kernel-headers/ seems like an obvious choice.
[...] these suggestion all make sense. I've incorporated them.
If we're talking about a new directory inside the QEMU tree, mind to name it linux-headers or so? There are other kernels besides The One. :)
Already called it precisely like this. :) I will re-post my series when the licensing things are clarified.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux