diff options
| author | Keir Fraser <keir.fraser@citrix.com> | 2010-09-13 17:31:19 +0100 |
|---|---|---|
| committer | Keir Fraser <keir.fraser@citrix.com> | 2010-09-13 17:31:19 +0100 |
| commit | c6b30186cdb4606552bb4de98fe449ef9a7400ec (patch) | |
| tree | d009d5f8d1469c8693c9e145655d2775821cd88f /config | |
| parent | 987c1f6080d05228ab81b27fad606af6c51537e4 (diff) | |
| download | xen-c6b30186cdb4606552bb4de98fe449ef9a7400ec.tar.gz xen-c6b30186cdb4606552bb4de98fe449ef9a7400ec.tar.bz2 xen-c6b30186cdb4606552bb4de98fe449ef9a7400ec.zip | |
Disable kernel build in Xen build system.
Cloning and building a kernel as part of the Xen distribution
implicitly advises that this kernel is the best kernel for all users
and many users appear to be under this impression, even though there
is no fundamental coupling between the Xen distribution and a
particular domain 0 kernel.
There are several choices available for domain 0 kernel, as well as
other user specific variations in requirements e.g. for kernel
configurations. It's not clear that whatever the xen build system
happens to produce (which is really tailored to the needs of the
automated build system) is best for anybody.
Coupling the kernel build with the Xen build has proved problematic
for stable Xen releases as it implicitly blesses the particular kernel
(at a particular point in time) as a constituent part of the Xen
release, while in reality the OS kernels are separate entities with
their own release cycles which may or may not coincide with the
maintenance of Xen stable branches.
Therefore disable the building of a kernel as part of the Xen
distribution by default and instead direct users to use an OS
distribution provided kernel (properly packaged with security updates
via the normal distribution mechanisms etc) where possible and give
pointers to suitable resources providing guidance for cases where it
is not.
This decouples the implicit advice as to the best kernel at any moment
from Xen's own release cycle and removes the implicit suggestion that
only particular domain 0 kernel will do.
The actual infrastructure is left in place since the automated test
system (currently) relies on it (but always asks for the specific
kernel variant it wants for a particular test).
(I also tried to remove Linux-isms from the README's Quick start
guide. In particular I'm not sure what was supposedly Linux specific
about steps 3 and 4 therefore I have removed the suggestion that they
are.)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Diffstat (limited to 'config')
| -rw-r--r-- | config/Linux.mk | 6 |
1 files changed, 1 insertions, 5 deletions
diff --git a/config/Linux.mk b/config/Linux.mk index 7d9286d7f1..10d84affb6 100644 --- a/config/Linux.mk +++ b/config/Linux.mk @@ -1,11 +1,7 @@ include $(XEN_ROOT)/config/StdGNU.mk # You may use wildcards, e.g. KERNELS=*2.6* -ifeq (ia64,$(XEN_TARGET_ARCH)) -KERNELS ?= linux-2.6-xen -else -KERNELS ?= linux-2.6-pvops -endif +KERNELS ?= XKERNELS := $(foreach kernel, $(KERNELS), \ $(patsubst buildconfigs/mk.%,%, \ |