Xen devel - Sep 2010 - [PATCH] disable kernel build in Xen build system

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1284113350 -3600
# Node ID 635270fe858be62c02ec2bf2cacd5fc7e2492a36
# Parent  ef7166e5640fd50c3041435f9233e3abcf12f698
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>

diff -r ef7166e5640f -r 635270fe858b README
--- a/README	Fri Sep 10 09:55:19 2010 +0100
+++ b/README	Fri Sep 10 11:09:10 2010 +0100
@@ -37,7 +37,7 @@ First, there are a number of prerequisit
 First, there are a number of prerequisites for building a Xen source
 release. Make sure you have all the following installed, either by
 visiting the project webpage or installing a pre-built package
-provided by your Linux distributor:
+provided by your OS distributor:
     * GCC v3.4 or later
     * GNU Make
     * GNU Binutils
@@ -51,13 +51,19 @@ provided by your Linux distributor:
     * hotplug or udev
     * GNU bison and GNU flex
 
+Second, you need to acquire a suitable kernel for use in domain 0. If
+possible you should use a kernel provided by your OS distributor. If
+no suitable kernel is available from your OS distributor then refer to
+http://wiki.xen.org/xenwiki/XenDom0Kernels for suggestions for
+suitable kernels to use.
+
 [NB. Unless noted otherwise, all the following steps should be
 performed with root privileges.]
 
 1. Download and untar the source tarball file. This will be a
    file named xen-unstable-src.tgz, or xen-$version-src.tgz.
    You can also pull the current version from the mercurial
-   repository at http://xenbits.xensource.com/
+   repository at http://xenbits.xen.org/
 
     # tar xzf xen-unstable-src.tgz
 
@@ -68,42 +74,23 @@ 1. Download and untar the source tarball
 
 2. cd to xen-unstable (or whatever you sensibly rename it to).
 
-On Linux:
-
-3. For the very first build, or if you want to destroy existing
-   .configs and build trees, perform the following steps:
+3. For the very first build, or if you want to destroy build trees,
+   perform the following steps:
 
     # make world
     # make install
 
    This will create and install onto the local machine. It will build
-   the xen binary (xen.gz), and a linux kernel and modules that can be
-   used in both dom0 and an unprivileged guest kernel (vmlinuz-2.6.x-xen),
-   the tools and the documentation.
+   the xen binary (xen.gz), the tools and the documentation.
 
    You can override the destination for make install by setting DESTDIR
    to some value.
 
-   The make command line defaults to building the kernel vmlinuz-2.6.x-xen.
-   You can override this default by specifying KERNELS=kernelname. For
-   example, you can make two kernels - linux-2.6-xen0
-   and linux-2.6-xenU - which are smaller builds containing only selected
-   modules, intended primarily for developers that don''t like to wait
-   for a full -xen kernel to build. The -xenU kernel is particularly small,
-   as it does not contain any physical device drivers, and hence is
-   only useful for guest domains.
-
-   To make these two kernels, simply specify
-
-   KERNELS="linux-2.6-xen0 linux-2.6-xenU"
-
-   in the make command line.
-
 4. To rebuild an existing tree without modifying the config:
     # make dist
 
-   This will build and install xen, kernels, tools, and
-   docs into the local dist/ directory.
+   This will build and install xen, tools, and docs into the local dist/
+   directory.
 
    You can override the destination for make install by setting DISTDIR
    to some value.
@@ -113,24 +100,7 @@ 4. To rebuild an existing tree without m
    version of hotplug or udev scripts, for example), but make dist
    includes all versions of those scripts, so that you can copy the dist
    directory to another machine and install from that distribution.
-
-5. To rebuild a kernel with a modified config:
-
-    # make linux-2.6-xen-config CONFIGMODE=menuconfig     (or xconfig)
-    # make linux-2.6-xen-build
-    # make linux-2.6-xen-install
-
-   Depending on your config, you may need to use ''mkinitrd''
to create
-   an initial ram disk, just like a native system e.g.
-    # depmod 2.6.18-xen
-    # mkinitrd -v -f --with=aacraid --with=sd_mod --with=scsi_mod
initrd-2.6.18-xen.img 2.6.18-xen
-
-   Other systems may requires the use of ''mkinitramfs'' to
create the
-   ram disk.
-    # depmod 2.6.18-xen
-    # mkinitramfs -o initrd-2.6.18-xen.img 2.6.18-xen
-
-
+   
 Python Runtime Libraries
 ======================= 
diff -r ef7166e5640f -r 635270fe858b config/Linux.mk
--- a/config/Linux.mk	Fri Sep 10 09:55:19 2010 +0100
+++ b/config/Linux.mk	Fri Sep 10 11:09:10 2010 +0100
@@ -1,11 +1,7 @@ include $(XEN_ROOT)/config/StdGNU.mk
 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.%,%, \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

I think it''s a good idea for the Xen build system not to include a
dom0 kernel.  However, it''s not very clear to a newcomer how to
actually get a kernel.  The xen.org download page has no links at all
to anything kernel-related.  There is a page on the wiki:

 http://wiki.xensource.com/xenwiki/XenDom0Kernels

However, the list is gigantic -- extremely intimidating.  And there''s
no generic version of the "classic" kernel; they''re all
branded XCP,
XCI, Novell, &c.

I think the Right Thing to do (given an ideal world), until pvops dom0
gets sufficiently upstreamed, is for xen.org to maintain two stable
releases: a reasonably stable pvops branch for the more adventurous,
and a classic xen port for the more conservative.

However, I don''t have the time to do that.  If we could find a
volunteer, I''m sure the community would be eternally grateful. :-)

 -George

On Fri, Sep 10, 2010 at 11:09 AM, Ian Campbell <ian.campbell@citrix.com>
wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1284113350 -3600
> # Node ID 635270fe858be62c02ec2bf2cacd5fc7e2492a36
> # Parent  ef7166e5640fd50c3041435f9233e3abcf12f698
> 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>
>
> diff -r ef7166e5640f -r 635270fe858b README
> --- a/README    Fri Sep 10 09:55:19 2010 +0100
> +++ b/README    Fri Sep 10 11:09:10 2010 +0100
> @@ -37,7 +37,7 @@ First, there are a number of prerequisit
>  First, there are a number of prerequisites for building a Xen source
>  release. Make sure you have all the following installed, either by
>  visiting the project webpage or installing a pre-built package
> -provided by your Linux distributor:
> +provided by your OS distributor:
>     * GCC v3.4 or later
>     * GNU Make
>     * GNU Binutils
> @@ -51,13 +51,19 @@ provided by your Linux distributor:
>     * hotplug or udev
>     * GNU bison and GNU flex
>
> +Second, you need to acquire a suitable kernel for use in domain 0. If
> +possible you should use a kernel provided by your OS distributor. If
> +no suitable kernel is available from your OS distributor then refer to
> +http://wiki.xen.org/xenwiki/XenDom0Kernels for suggestions for
> +suitable kernels to use.
> +
>  [NB. Unless noted otherwise, all the following steps should be
>  performed with root privileges.]
>
>  1. Download and untar the source tarball file. This will be a
>    file named xen-unstable-src.tgz, or xen-$version-src.tgz.
>    You can also pull the current version from the mercurial
> -   repository at http://xenbits.xensource.com/
> +   repository at http://xenbits.xen.org/
>
>     # tar xzf xen-unstable-src.tgz
>
> @@ -68,42 +74,23 @@ 1. Download and untar the source tarball
>
>  2. cd to xen-unstable (or whatever you sensibly rename it to).
>
> -On Linux:
> -
> -3. For the very first build, or if you want to destroy existing
> -   .configs and build trees, perform the following steps:
> +3. For the very first build, or if you want to destroy build trees,
> +   perform the following steps:
>
>     # make world
>     # make install
>
>    This will create and install onto the local machine. It will build
> -   the xen binary (xen.gz), and a linux kernel and modules that can be
> -   used in both dom0 and an unprivileged guest kernel (vmlinuz-2.6.x-xen),
> -   the tools and the documentation.
> +   the xen binary (xen.gz), the tools and the documentation.
>
>    You can override the destination for make install by setting DESTDIR
>    to some value.
>
> -   The make command line defaults to building the kernel
vmlinuz-2.6.x-xen.
> -   You can override this default by specifying KERNELS=kernelname. For
> -   example, you can make two kernels - linux-2.6-xen0
> -   and linux-2.6-xenU - which are smaller builds containing only selected
> -   modules, intended primarily for developers that don''t like to
wait
> -   for a full -xen kernel to build. The -xenU kernel is particularly
small,
> -   as it does not contain any physical device drivers, and hence is
> -   only useful for guest domains.
> -
> -   To make these two kernels, simply specify
> -
> -   KERNELS="linux-2.6-xen0 linux-2.6-xenU"
> -
> -   in the make command line.
> -
>  4. To rebuild an existing tree without modifying the config:
>     # make dist
>
> -   This will build and install xen, kernels, tools, and
> -   docs into the local dist/ directory.
> +   This will build and install xen, tools, and docs into the local dist/
> +   directory.
>
>    You can override the destination for make install by setting DISTDIR
>    to some value.
> @@ -113,24 +100,7 @@ 4. To rebuild an existing tree without m
>    version of hotplug or udev scripts, for example), but make dist
>    includes all versions of those scripts, so that you can copy the dist
>    directory to another machine and install from that distribution.
> -
> -5. To rebuild a kernel with a modified config:
> -
> -    # make linux-2.6-xen-config CONFIGMODE=menuconfig     (or xconfig)
> -    # make linux-2.6-xen-build
> -    # make linux-2.6-xen-install
> -
> -   Depending on your config, you may need to use
''mkinitrd'' to create
> -   an initial ram disk, just like a native system e.g.
> -    # depmod 2.6.18-xen
> -    # mkinitrd -v -f --with=aacraid --with=sd_mod --with=scsi_mod
initrd-2.6.18-xen.img 2.6.18-xen
> -
> -   Other systems may requires the use of ''mkinitramfs''
to create the
> -   ram disk.
> -    # depmod 2.6.18-xen
> -    # mkinitramfs -o initrd-2.6.18-xen.img 2.6.18-xen
> -
> -
> +
>  Python Runtime Libraries
>  =======================>
> diff -r ef7166e5640f -r 635270fe858b config/Linux.mk
> --- a/config/Linux.mk   Fri Sep 10 09:55:19 2010 +0100
> +++ b/config/Linux.mk   Fri Sep 10 11:09:10 2010 +0100
> @@ -1,11 +1,7 @@ include $(XEN_ROOT)/config/StdGNU.mk
>  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.%,%, \
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Sep 10, George Dunlap wrote:
> I think it''s a good idea for the Xen build system not to include a
> dom0 kernel.  However, it''s not very clear to a newcomer how to
> actually get a kernel.  The xen.org download page has no links at all
> to anything kernel-related.  There is a page on the wiki:
> 
>  http://wiki.xensource.com/xenwiki/XenDom0Kernels
> 
> However, the list is gigantic -- extremely intimidating.  And
there''s
> no generic version of the "classic" kernel; they''re all
branded XCP,
> XCI, Novell, &c.
> 
> I think the Right Thing to do (given an ideal world), until pvops dom0
> gets sufficiently upstreamed, is for xen.org to maintain two stable
> releases: a reasonably stable pvops branch for the more adventurous,
> and a classic xen port for the more conservative.
George,

I second that. The first time I looked at this page all it caused was
confusion. It gives the impression of "there is no upstream". If we
could get some sort of reference where all the fixes go, that would help
alot.
I would help out with maintaining such a tree.

Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Sep 10, 2010 at 01:57:41PM +0200, Olaf Hering
wrote:
> On Fri, Sep 10, George Dunlap wrote:
> 
> > I think it''s a good idea for the Xen build system not to
include a
> > dom0 kernel.  However, it''s not very clear to a newcomer how
to
> > actually get a kernel.  The xen.org download page has no links at all
> > to anything kernel-related.  There is a page on the wiki:
> > 
> >  http://wiki.xensource.com/xenwiki/XenDom0Kernels
> > 
> > However, the list is gigantic -- extremely intimidating.  And
there''s
> > no generic version of the "classic" kernel; they''re
all branded XCP,
> > XCI, Novell, &c.
> > 
> > I think the Right Thing to do (given an ideal world), until pvops dom0
> > gets sufficiently upstreamed, is for xen.org to maintain two stable
> > releases: a reasonably stable pvops branch for the more adventurous,
> > and a classic xen port for the more conservative.
> 
> George,
> 
> I second that. The first time I looked at this page all it caused was
> confusion. It gives the impression of "there is no upstream". If
we
> could get some sort of reference where all the fixes go, that would help
> alot.
> I would help out with maintaining such a tree.
> 
Yeah, the XenDom0Kernels wiki page has gotten pretty unclear.

I guess for users, at the moment, the two ''main'' kernels that
are maintained and bugfixed by xen.org are:

- pvops xen/stable-2.6.32.x
- xenlinux xcp/xenserver 2.6.32.x 

I can try to clear up the wiki page if we can agree on what to write there :)

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 2010-09-10 at 12:04 +0100, George Dunlap wrote:
> I think the Right Thing to do (given an ideal world), until pvops dom0
> gets sufficiently upstreamed, is for xen.org to maintain two stable
> releases: a reasonably stable pvops branch for the more adventurous,
> and a classic xen port for the more conservative.
Thanks George. I agree that improving the resources to guide users here
is an important part of this change. I think a prominent message in the
4.1 release notes is a must too.
> However, I don''t have the time to do that.  If we could find a
> volunteer, I''m sure the community would be eternally grateful. :-)
I certainly would!

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 2010-09-10 at 13:06 +0100, Pasi Kärkkäinen wrote:
> I guess for users, at the moment, the two ''main'' kernels
that
> are maintained and bugfixed by xen.org are:
> 
> - pvops xen/stable-2.6.32.x
> - xenlinux xcp/xenserver 2.6.32.x 
> 
> I can try to clear up the wiki page if we can agree on what to write
> there :)
Thanks Pasi!

I think most users (rather than devs) should be guided to try and use a
distro provided kernel if possible. For devs and those whose distro does
not provide something suitable then I think the two kernels you have
mentioned would be the right two to focus on.

I think keeping this particular page short would help. e.g. a short
overview followed by a short description pros+cons and a link to the
exact source code repositories for both kernels. Anything else could go
on a kernel type specific wiki page with the gory details on cloning,
building, installing, recommended configurations etc.

We should probably also make it clear that the pvops one is the target
for all new development and perhaps point to the relevant more dev
oriented branch and/or wiki page.

The majority of the current content for all the other kernels could
probably be moved to a separate AlternativeDom0Kernels page or to their
own individual pages.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ian Campbell writes ("[Xen-devel] [PATCH] disable kernel build in Xen build
system"):
> disable kernel build in Xen build system.
I think this is a very sensible idea.  Ian''s patch already contains an
update to the README.  I''m inclined to apply it as-is, and let people
improve the documentation or the wiki later.  But I''ll hold off in
case someone has some comments.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 10 Sep 2010, Pasi K??rkk??inen wrote:
> On Fri, Sep 10, 2010 at 01:57:41PM +0200, Olaf Hering wrote:
> > On Fri, Sep 10, George Dunlap wrote:
> > 
> > > I think it''s a good idea for the Xen build system not to
include a
> > > dom0 kernel.  However, it''s not very clear to a newcomer
how to
> > > actually get a kernel.  The xen.org download page has no links at
all
> > > to anything kernel-related.  There is a page on the wiki:
> > > 
> > >  http://wiki.xensource.com/xenwiki/XenDom0Kernels
> > > 
> > > However, the list is gigantic -- extremely intimidating.  And
there''s
> > > no generic version of the "classic" kernel;
they''re all branded XCP,
> > > XCI, Novell, &c.
> > > 
> > > I think the Right Thing to do (given an ideal world), until pvops
dom0
> > > gets sufficiently upstreamed, is for xen.org to maintain two
stable
> > > releases: a reasonably stable pvops branch for the more
adventurous,
> > > and a classic xen port for the more conservative.
> > 
> > George,
> > 
> > I second that. The first time I looked at this page all it caused was
> > confusion. It gives the impression of "there is no
upstream". If we
> > could get some sort of reference where all the fixes go, that would
help
> > alot.
> > I would help out with maintaining such a tree.
> > 
> 
> Yeah, the XenDom0Kernels wiki page has gotten pretty unclear.
> 
> I guess for users, at the moment, the two ''main'' kernels
that
> are maintained and bugfixed by xen.org are:
> 
> - pvops xen/stable-2.6.32.x
> - xenlinux xcp/xenserver 2.6.32.x 
> 
> I can try to clear up the wiki page if we can agree on what to write there
:)
> 
I gave a look at the page and I think it is still too verbose for
newcomers.
A detailed explanation of the current situation is fine, but above that
we need two simple lines with a link.

I propose something like this:

---

***Xen dom0 kernels Quick Start***
If you don''t know exactly what a dom0 kernel is, read the detailed
explanation below.
If you want to install the Xen hypervisor for production use but your
distro doesn''t provide a dom0 kernel, just grab one of the latest
"XenLinux" port here:

- Citrix XenServer / XCP Linux 2.6.32 kernel (source and tarball link)

- Novell SLES11 Linux 2.6.32 Xen kernel (source and tarball link)

---

We definitely need to provide both a source tree and a source tarball
for each option; ideally we should provide a deb/rpm too.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Sep 21, 2010 at 05:30:18PM +0100, Stefano Stabellini
wrote:
> On Fri, 10 Sep 2010, Pasi K??rkk??inen wrote:
> > On Fri, Sep 10, 2010 at 01:57:41PM +0200, Olaf Hering wrote:
> > > On Fri, Sep 10, George Dunlap wrote:
> > > 
> > > > I think it''s a good idea for the Xen build system
not to include a
> > > > dom0 kernel.  However, it''s not very clear to a
newcomer how to
> > > > actually get a kernel.  The xen.org download page has no
links at all
> > > > to anything kernel-related.  There is a page on the wiki:
> > > > 
> > > >  http://wiki.xensource.com/xenwiki/XenDom0Kernels
> > > > 
> > > > However, the list is gigantic -- extremely intimidating. 
And there''s
> > > > no generic version of the "classic" kernel;
they''re all branded XCP,
> > > > XCI, Novell, &c.
> > > > 
> > > > I think the Right Thing to do (given an ideal world), until
pvops dom0
> > > > gets sufficiently upstreamed, is for xen.org to maintain two
stable
> > > > releases: a reasonably stable pvops branch for the more
adventurous,
> > > > and a classic xen port for the more conservative.
> > > 
> > > George,
> > > 
> > > I second that. The first time I looked at this page all it caused
was
> > > confusion. It gives the impression of "there is no
upstream". If we
> > > could get some sort of reference where all the fixes go, that
would help
> > > alot.
> > > I would help out with maintaining such a tree.
> > > 
> > 
> > Yeah, the XenDom0Kernels wiki page has gotten pretty unclear.
> > 
> > I guess for users, at the moment, the two ''main''
kernels that
> > are maintained and bugfixed by xen.org are:
> > 
> > - pvops xen/stable-2.6.32.x
> > - xenlinux xcp/xenserver 2.6.32.x 
> > 
> > I can try to clear up the wiki page if we can agree on what to write
there :)
> > 
> 
> I gave a look at the page and I think it is still too verbose for
> newcomers.
> A detailed explanation of the current situation is fine, but above that
> we need two simple lines with a link.
> 
Yep, I didn''t have time to fix the page yet :)

> I propose something like this:
> 
> ---
> 
> ***Xen dom0 kernels Quick Start***
> If you don''t know exactly what a dom0 kernel is, read the detailed
> explanation below.
> If you want to install the Xen hypervisor for production use but your
> distro doesn''t provide a dom0 kernel, just grab one of the latest
> "XenLinux" port here:
> 
> - Citrix XenServer / XCP Linux 2.6.32 kernel (source and tarball link)
> 
> - Novell SLES11 Linux 2.6.32 Xen kernel (source and tarball link)
> 
> ---
> 
> We definitely need to provide both a source tree and a source tarball
> for each option; ideally we should provide a deb/rpm too.
> 
Indeed.

-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel