| Message ID | 20200930125736.95203-1-george.dunlap@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] docs: Add minimum version depencency policy document | expand |
On 30.09.2020 14:57, George Dunlap wrote: > --- /dev/null > +++ b/docs/policies/dependency-versions.rst > @@ -0,0 +1,76 @@ > +.. SPDX-License-Identifier: CC-BY-4.0 > + > +Build and runtime dependencies > +============================== > + > +Xen depends on other programs and libraries to build and to run. > +Chosing a minimum version of these tools to support requires a careful > +balance: Supporting older versions of these tools or libraries means > +that Xen can compile on a wider variety of systems; but means that Xen > +cannot take advantage of features available in newer versions. > +Conversely, requiring newer versions means that Xen can take advantage > +of newer features, but cannot work on as wide a variety of systems. I think "cannot take advantage" is too strict here: It may be more cumbersome (and as a result to ugly to maintain), but it ought to generally be possible. IOW how about adding "easily"? > +Specific distro versions supported in this release > +-------------------------------------------------- > + > +======== ================== > +Distro Supported releases > +======== ================== > +Debian 10 (Buster) > +Ubuntu 20.10 (Groovy Gorilla), 20.04 (Focal Fossa), 18.04 (Bionic Beaver), 16.04 (Xenial Xerus) > +OpenSUSE Leap 15.2 > +SLES SLES 11, 12, 15 SLE 11 has all support packs in LTSS mode already, so as long as this mode is what's equivalent to or even less than "Maintenance updates" in what you did say for RHEL, it may want dropping. (Personally I'd prefer if we remained sufficiently compatible, but I realize I may be the only one.) Additionally in service packs things like compiler or binutils versions often get updated, so e.g. "SLES 11" alone is not sufficient to know what's meant to be supported, it would likely need to be "SLES 11 SP4" and alike, just like you also specify a minor version for some of the other distros. SLES versions not yet in LTSS at this point are, if I'm not mistaken, 12 SP5, 15 SP1, and 15 SP2. Jan
> On Sep 30, 2020, at 2:11 PM, Jan Beulich <jbeulich@suse.com> wrote: > > On 30.09.2020 14:57, George Dunlap wrote: >> --- /dev/null >> +++ b/docs/policies/dependency-versions.rst >> @@ -0,0 +1,76 @@ >> +.. SPDX-License-Identifier: CC-BY-4.0 >> + >> +Build and runtime dependencies >> +============================== >> + >> +Xen depends on other programs and libraries to build and to run. >> +Chosing a minimum version of these tools to support requires a careful >> +balance: Supporting older versions of these tools or libraries means >> +that Xen can compile on a wider variety of systems; but means that Xen >> +cannot take advantage of features available in newer versions. >> +Conversely, requiring newer versions means that Xen can take advantage >> +of newer features, but cannot work on as wide a variety of systems. > > I think "cannot take advantage" is too strict here: It may be more > cumbersome (and as a result to ugly to maintain), but it ought to > generally be possible. IOW how about adding "easily"? Sure. >> +Specific distro versions supported in this release >> +-------------------------------------------------- >> + >> +======== ================== >> +Distro Supported releases >> +======== ================== >> +Debian 10 (Buster) >> +Ubuntu 20.10 (Groovy Gorilla), 20.04 (Focal Fossa), 18.04 (Bionic Beaver), 16.04 (Xenial Xerus) >> +OpenSUSE Leap 15.2 >> +SLES SLES 11, 12, 15 > > SLE 11 has all support packs in LTSS mode already, so as long as this > mode is what's equivalent to or even less than "Maintenance updates" > in what you did say for RHEL, it may want dropping. (Personally I'd > prefer if we remained sufficiently compatible, but I realize I may be > the only one.) > > Additionally in service packs things like compiler or binutils versions > often get updated, so e.g. "SLES 11" alone is not sufficient to know > what's meant to be supported, it would likely need to be "SLES 11 SP4" > and alike, just like you also specify a minor version for some of the > other distros. SLES versions not yet in LTSS at this point are, if I'm > not mistaken, 12 SP5, 15 SP1, and 15 SP2. Right, part of the reason this is ‘RFC’ is to get feedback from people who actually know something about their various distros. The list above was made by trying to make sense of the table in the link above (https://www.suse.com/lifecycle/). I think it’s important to have references such that the release manager can easily update this list every release. Do you think you could provide a better link? Thanks, -George
On 30.09.2020 15:29, George Dunlap wrote:
> The list above was made by trying to make sense of the table in the link above (https://www.suse.com/lifecycle/). I think it’s important to have references such that the release manager can easily update this list every release. Do you think you could provide a better link?
I don't think I can; the link is good for what we want, I think.
When expanding the individual version lines, information on the
life times of the service packs is shown, and I think that's all
we need here.
Jan
On Wed, 30 Sep 2020, George Dunlap wrote: > Define a specific criteria for how we determine what tools and > libraries to be compatible with. This will clarify issues such as, > "Should we continue to support Python 2.4" moving forward. > > Note that CentOS 7 is set to stop receiving "normal" maintenance > updates in "Q4 2020"; assuming that 4.15 is released after that, we > only need to support CentOS / RHEL 8. > > Signed-off-by: George Dunlap <george.dunlap@citrix.com> > --- > > CC: Ian Jackson <ian.jackson@citrix.com> > CC: Wei Liu <wl@xen.org> > CC: Andrew Cooper <andrew.cooper3@citrix.com> > CC: Jan Beulich <jbeulich@suse.com> > CC: Stefano Stabellini <sstabellini@kernel.org> > CC: Julien Grall <julien@xen.org> > CC: Rich Persaud <persaur@gmail.com> > CC: Bertrand Marquis <Bertrand.Marquis@arm.com> > --- > docs/index.rst | 2 + > docs/policies/dependency-versions.rst | 76 +++++++++++++++++++++++++++ > 2 files changed, 78 insertions(+) > create mode 100644 docs/policies/dependency-versions.rst > > diff --git a/docs/index.rst b/docs/index.rst > index b75487a05d..ac175eacc8 100644 > --- a/docs/index.rst > +++ b/docs/index.rst > @@ -57,5 +57,7 @@ Miscellanea > ----------- > > .. toctree:: > + :maxdepth: 1 > > + policies/dependency-versions > glossary > diff --git a/docs/policies/dependency-versions.rst b/docs/policies/dependency-versions.rst > new file mode 100644 > index 0000000000..d5eeb848d8 > --- /dev/null > +++ b/docs/policies/dependency-versions.rst > @@ -0,0 +1,76 @@ > +.. SPDX-License-Identifier: CC-BY-4.0 > + > +Build and runtime dependencies > +============================== > + > +Xen depends on other programs and libraries to build and to run. > +Chosing a minimum version of these tools to support requires a careful > +balance: Supporting older versions of these tools or libraries means > +that Xen can compile on a wider variety of systems; but means that Xen > +cannot take advantage of features available in newer versions. > +Conversely, requiring newer versions means that Xen can take advantage > +of newer features, but cannot work on as wide a variety of systems. > + > +Specific dependencies and versions for a given Xen release will be > +listed in the toplevel README, and/or specified by the ``configure`` > +system. This document lays out the principles by which those versions > +should be chosen. > + > +The general principle is this: > + > + Xen should build on currently-supported versions of major distros > + when released. > + > +"Currently-supported" means whatever that distro's version of "full > +support". For instance, at the time of writing, CentOS 7 and 8 are > +listed as being given "Full Updates", but CentOS 6 is listed as > +"Maintenance updates"; under this criterium, we would try to ensure > +that Xen could build on CentOS 7 and 8, but not on CentOS 6. > + > +Exceptions for specific distros or tools may be made when appropriate. > + > +One exception to this is compiler versions for the hypervisor. > +Support for new instructions, and in particular support for new safety > +features, may require a newer compiler than many distros support. > +These will be specified in the README. > + > +Distros we consider when deciding minimum versions > +-------------------------------------------------- > + > +We currently aim to support Xen building and running on the following distributions: > +Debian_, > +Ubuntu_, > +OpenSUSE_, > +Arch Linux, > +SLES_, > +Yocto_, > +CentOS_, > +and RHEL_. Alpine Linux should be in the list (consider its usage in container environment.) > + > +.. _Debian: https://www.debian.org/releases/ > +.. _Ubuntu: https://wiki.ubuntu.com/Releases > +.. _OpenSUSE: https://en.opensuse.org/Lifetime > +.. _SLES: https://www.suse.com/lifecycle/ > +.. _Yocto: https://wiki.yoctoproject.org/wiki/Releases > +.. _CentOS: https://wiki.centos.org/About/Product > +.. _RHEL: https://access.redhat.com/support/policy/updates/errata > + > +Specific distro versions supported in this release > +-------------------------------------------------- > + > +======== ================== > +Distro Supported releases > +======== ================== > +Debian 10 (Buster) > +Ubuntu 20.10 (Groovy Gorilla), 20.04 (Focal Fossa), 18.04 (Bionic Beaver), 16.04 (Xenial Xerus) > +OpenSUSE Leap 15.2 > +SLES SLES 11, 12, 15 > +Yocto 3.1 (Dunfell) > +CentOS 8 > +RHEL 8 > +======== ================== > I am still on Alpine Linux 3.7, so I am sure that one works. Probably other versions work too.
> On Sep 30, 2020, at 9:23 PM, Stefano Stabellini <sstabellini@kernel.org> wrote: > > On Wed, 30 Sep 2020, George Dunlap wrote: >> Define a specific criteria for how we determine what tools and >> libraries to be compatible with. This will clarify issues such as, >> "Should we continue to support Python 2.4" moving forward. >> >> Note that CentOS 7 is set to stop receiving "normal" maintenance >> updates in "Q4 2020"; assuming that 4.15 is released after that, we >> only need to support CentOS / RHEL 8. >> >> Signed-off-by: George Dunlap <george.dunlap@citrix.com> >> --- >> >> CC: Ian Jackson <ian.jackson@citrix.com> >> CC: Wei Liu <wl@xen.org> >> CC: Andrew Cooper <andrew.cooper3@citrix.com> >> CC: Jan Beulich <jbeulich@suse.com> >> CC: Stefano Stabellini <sstabellini@kernel.org> >> CC: Julien Grall <julien@xen.org> >> CC: Rich Persaud <persaur@gmail.com> >> CC: Bertrand Marquis <Bertrand.Marquis@arm.com> >> --- >> docs/index.rst | 2 + >> docs/policies/dependency-versions.rst | 76 +++++++++++++++++++++++++++ >> 2 files changed, 78 insertions(+) >> create mode 100644 docs/policies/dependency-versions.rst >> >> diff --git a/docs/index.rst b/docs/index.rst >> index b75487a05d..ac175eacc8 100644 >> --- a/docs/index.rst >> +++ b/docs/index.rst >> @@ -57,5 +57,7 @@ Miscellanea >> ----------- >> >> .. toctree:: >> + :maxdepth: 1 >> >> + policies/dependency-versions >> glossary >> diff --git a/docs/policies/dependency-versions.rst b/docs/policies/dependency-versions.rst >> new file mode 100644 >> index 0000000000..d5eeb848d8 >> --- /dev/null >> +++ b/docs/policies/dependency-versions.rst >> @@ -0,0 +1,76 @@ >> +.. SPDX-License-Identifier: CC-BY-4.0 >> + >> +Build and runtime dependencies >> +============================== >> + >> +Xen depends on other programs and libraries to build and to run. >> +Chosing a minimum version of these tools to support requires a careful >> +balance: Supporting older versions of these tools or libraries means >> +that Xen can compile on a wider variety of systems; but means that Xen >> +cannot take advantage of features available in newer versions. >> +Conversely, requiring newer versions means that Xen can take advantage >> +of newer features, but cannot work on as wide a variety of systems. >> + >> +Specific dependencies and versions for a given Xen release will be >> +listed in the toplevel README, and/or specified by the ``configure`` >> +system. This document lays out the principles by which those versions >> +should be chosen. >> + >> +The general principle is this: >> + >> + Xen should build on currently-supported versions of major distros >> + when released. >> + >> +"Currently-supported" means whatever that distro's version of "full >> +support". For instance, at the time of writing, CentOS 7 and 8 are >> +listed as being given "Full Updates", but CentOS 6 is listed as >> +"Maintenance updates"; under this criterium, we would try to ensure >> +that Xen could build on CentOS 7 and 8, but not on CentOS 6. >> + >> +Exceptions for specific distros or tools may be made when appropriate. >> + >> +One exception to this is compiler versions for the hypervisor. >> +Support for new instructions, and in particular support for new safety >> +features, may require a newer compiler than many distros support. >> +These will be specified in the README. >> + >> +Distros we consider when deciding minimum versions >> +-------------------------------------------------- >> + >> +We currently aim to support Xen building and running on the following distributions: >> +Debian_, >> +Ubuntu_, >> +OpenSUSE_, >> +Arch Linux, >> +SLES_, >> +Yocto_, >> +CentOS_, >> +and RHEL_. > > Alpine Linux should be in the list (consider its usage in container > environment.) Sure, we can add that one in. Although, we might consider requiring that distros on this list be first be added to the Gitlab CI loop if possible. > I am still on Alpine Linux 3.7, so I am sure that one works. Probably > other versions work too. Right, but the question is, if someone posts a patch which causes it to no longer build on 3.7, would we reject it or accept it? According to https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases, only 3.12 is currently receiving bug fixes; so by the criteria above, we would only reject a changeset if it caused a build regression for 3.12. I would argue that this is the right approach: It doesn’t make sense for us to spend more effort keeping an old distro working than that community it self spends keeping it working. The Ubuntu community spends effort keeping Ubuntu 16.04 in working shape, so it makes sense for us to spend effort making sure Xen 4.15 builds and runs on it. The Alpine Linux community doesn’t promise to spend any effort to fix any more bugs in Alpine Linux 3.11, so it doesn’t make any sense for us to spend effort making sure Xen 4.15 runs on it. Obviously if it builds on Ubuntu 16.04 there’s a pretty high probability that it will also build on Alpine Linux 3.4+ (released around the same time); we just don’t want to promise that. -George
On 30/09/2020 13:57, George Dunlap wrote: > Define a specific criteria for how we determine what tools and > libraries to be compatible with. This will clarify issues such as, > "Should we continue to support Python 2.4" moving forward. Luckily that one is settled. Arguably a better option might be "what is the minimum toolchain to support" ? > Note that CentOS 7 is set to stop receiving "normal" maintenance > updates in "Q4 2020"; assuming that 4.15 is released after that, we > only need to support CentOS / RHEL 8. While I appreciate that this doesn't mean "we'll break CentOS 7 in Q4", I'm going to have some substantial development issues if C7 actually stops working, at least in the short to medium term. > > Signed-off-by: George Dunlap <george.dunlap@citrix.com> > --- > > CC: Ian Jackson <ian.jackson@citrix.com> > CC: Wei Liu <wl@xen.org> > CC: Andrew Cooper <andrew.cooper3@citrix.com> > CC: Jan Beulich <jbeulich@suse.com> > CC: Stefano Stabellini <sstabellini@kernel.org> > CC: Julien Grall <julien@xen.org> > CC: Rich Persaud <persaur@gmail.com> > CC: Bertrand Marquis <Bertrand.Marquis@arm.com> > --- > docs/index.rst | 2 + > docs/policies/dependency-versions.rst | 76 +++++++++++++++++++++++++++ > 2 files changed, 78 insertions(+) > create mode 100644 docs/policies/dependency-versions.rst > > diff --git a/docs/index.rst b/docs/index.rst > index b75487a05d..ac175eacc8 100644 > --- a/docs/index.rst > +++ b/docs/index.rst > @@ -57,5 +57,7 @@ Miscellanea > ----------- > > .. toctree:: > + :maxdepth: 1 > > + policies/dependency-versions I think it is great that this is going into Sphinx. However, I'd prefer to avoid proliferating random things at the top level, to try and keep everything in a coherent structure. For better or worse, I guestimated at "admin guide" (end user and sysadmin guide), "guest docs" (VM ABI, and guest kernel developers), and "hypervisors docs" (hacking Xen). I'm happy to shuffle the dividing lines if a better arrangement becomes obvious. This particular doc logically lives with "building Xen from source". Alternatively, I considered putting in an explicit "unsorted" section in the short term, so content can get added, and still be clear that it isn't in its final resting place. > glossary > diff --git a/docs/policies/dependency-versions.rst b/docs/policies/dependency-versions.rst > new file mode 100644 > index 0000000000..d5eeb848d8 > --- /dev/null > +++ b/docs/policies/dependency-versions.rst > @@ -0,0 +1,76 @@ > +.. SPDX-License-Identifier: CC-BY-4.0 > + > +Build and runtime dependencies > +============================== > + > +Xen depends on other programs and libraries to build and to run. > +Chosing a minimum version of these tools to support requires a careful > +balance: Supporting older versions of these tools or libraries means > +that Xen can compile on a wider variety of systems; but means that Xen > +cannot take advantage of features available in newer versions. > +Conversely, requiring newer versions means that Xen can take advantage > +of newer features, but cannot work on as wide a variety of systems. > + > +Specific dependencies and versions for a given Xen release will be > +listed in the toplevel README, and/or specified by the ``configure`` > +system. This document lays out the principles by which those versions > +should be chosen. > + > +The general principle is this: > + > + Xen should build on currently-supported versions of major distros > + when released. > + > +"Currently-supported" means whatever that distro's version of "full > +support". For instance, at the time of writing, CentOS 7 and 8 are > +listed as being given "Full Updates", but CentOS 6 is listed as > +"Maintenance updates"; under this criterium, we would try to ensure > +that Xen could build on CentOS 7 and 8, but not on CentOS 6. > + > +Exceptions for specific distros or tools may be made when appropriate. > + > +One exception to this is compiler versions for the hypervisor. > +Support for new instructions, and in particular support for new safety > +features, may require a newer compiler than many distros support. > +These will be specified in the README. The problem we have is that xen.git contains two very different things. There is the hypervisor itself, which is embedded, and can easily be cross compiled, and there is the content of tools/ which depends on a lot of distro infrastructure. We expect tools/ to work in any supported distro, without having to do weird toolchain gymnastics. For xen/ at the moment we have a very obsolete toolchain requirements, and this is holding us back in some areas. We're looking to bring that forward, and may consider that being newer than some of the old distros is necessary. At the moment however, we have quite a lot of functionality which is dependent on being able to detect suitable toolchain. GCOV and CET-SS are examples. These features will turn themselves off in older distros, so while you can "build" Xen that far back, you might not get everything. For CET in particular, there is no feasible way to support it on older toolchains. (unless someone comes up with an extremely convincing way of hand-crafting memory operands using raw .byte's in inline assembler.) I definitely don't think it is unreasonable for us to require the use of (potentially) bleeding edge toolchains if they want to use (potentially) bleeding edge features. CET-SS isn't bleeding edge any more, but CET-IBT is due to the additional linker work required to make it function. A future one which we need to do something about is Control Flow Integrity, which is Clang specific, depends on LTO, and caused Linux to up their minimum supported version to 10.0.1 which was when all the bugfixes got merged. > + > +Distros we consider when deciding minimum versions > +-------------------------------------------------- > + > +We currently aim to support Xen building and running on the following distributions: > +Debian_, > +Ubuntu_, > +OpenSUSE_, > +Arch Linux, No link for Arch? > +SLES_, > +Yocto_, > +CentOS_, > +and RHEL_. > + > +.. _Debian: https://www.debian.org/releases/ > +.. _Ubuntu: https://wiki.ubuntu.com/Releases > +.. _OpenSUSE: https://en.opensuse.org/Lifetime > +.. _SLES: https://www.suse.com/lifecycle/ > +.. _Yocto: https://wiki.yoctoproject.org/wiki/Releases > +.. _CentOS: https://wiki.centos.org/About/Product > +.. _RHEL: https://access.redhat.com/support/policy/updates/errata > + > +Specific distro versions supported in this release > +-------------------------------------------------- > + > +======== ================== > +Distro Supported releases > +======== ================== > +Debian 10 (Buster) > +Ubuntu 20.10 (Groovy Gorilla), 20.04 (Focal Fossa), 18.04 (Bionic Beaver), 16.04 (Xenial Xerus) > +OpenSUSE Leap 15.2 > +SLES SLES 11, 12, 15 > +Yocto 3.1 (Dunfell) > +CentOS 8 > +RHEL 8 > +======== ================== How about a 3rd column for "supported until" ? It would stop this page becoming stale simply over time. > + > +.. note:: > + > + We also support Arch Linux, but as it's a rolling distribution, the > + concept of "security supported releases" doesn't really apply. Should we rationalise this list with the docker containers? ~Andrew
Hi George, + Christopher Clark to have his view on what to put for Yocto. > On 30 Sep 2020, at 13:57, George Dunlap <george.dunlap@citrix.com> wrote: > > Define a specific criteria for how we determine what tools and > libraries to be compatible with. This will clarify issues such as, > "Should we continue to support Python 2.4" moving forward. > > Note that CentOS 7 is set to stop receiving "normal" maintenance > updates in "Q4 2020"; assuming that 4.15 is released after that, we > only need to support CentOS / RHEL 8. > > Signed-off-by: George Dunlap <george.dunlap@citrix.com> > --- > > CC: Ian Jackson <ian.jackson@citrix.com> > CC: Wei Liu <wl@xen.org> > CC: Andrew Cooper <andrew.cooper3@citrix.com> > CC: Jan Beulich <jbeulich@suse.com> > CC: Stefano Stabellini <sstabellini@kernel.org> > CC: Julien Grall <julien@xen.org> > CC: Rich Persaud <persaur@gmail.com> > CC: Bertrand Marquis <Bertrand.Marquis@arm.com> > --- > docs/index.rst | 2 + > docs/policies/dependency-versions.rst | 76 +++++++++++++++++++++++++++ > 2 files changed, 78 insertions(+) > create mode 100644 docs/policies/dependency-versions.rst > > diff --git a/docs/index.rst b/docs/index.rst > index b75487a05d..ac175eacc8 100644 > --- a/docs/index.rst > +++ b/docs/index.rst > @@ -57,5 +57,7 @@ Miscellanea > ----------- > > .. toctree:: > + :maxdepth: 1 > > + policies/dependency-versions > glossary > diff --git a/docs/policies/dependency-versions.rst b/docs/policies/dependency-versions.rst > new file mode 100644 > index 0000000000..d5eeb848d8 > --- /dev/null > +++ b/docs/policies/dependency-versions.rst > @@ -0,0 +1,76 @@ > +.. SPDX-License-Identifier: CC-BY-4.0 > + > +Build and runtime dependencies > +============================== > + > +Xen depends on other programs and libraries to build and to run. > +Chosing a minimum version of these tools to support requires a careful > +balance: Supporting older versions of these tools or libraries means > +that Xen can compile on a wider variety of systems; but means that Xen > +cannot take advantage of features available in newer versions. > +Conversely, requiring newer versions means that Xen can take advantage > +of newer features, but cannot work on as wide a variety of systems. > + > +Specific dependencies and versions for a given Xen release will be > +listed in the toplevel README, and/or specified by the ``configure`` > +system. This document lays out the principles by which those versions > +should be chosen. > + > +The general principle is this: > + > + Xen should build on currently-supported versions of major distros > + when released. > + > +"Currently-supported" means whatever that distro's version of "full > +support". For instance, at the time of writing, CentOS 7 and 8 are > +listed as being given "Full Updates", but CentOS 6 is listed as > +"Maintenance updates"; under this criterium, we would try to ensure > +that Xen could build on CentOS 7 and 8, but not on CentOS 6. > + > +Exceptions for specific distros or tools may be made when appropriate. > + > +One exception to this is compiler versions for the hypervisor. > +Support for new instructions, and in particular support for new safety > +features, may require a newer compiler than many distros support. > +These will be specified in the README. > + > +Distros we consider when deciding minimum versions > +-------------------------------------------------- > + > +We currently aim to support Xen building and running on the following distributions: > +Debian_, > +Ubuntu_, > +OpenSUSE_, > +Arch Linux, > +SLES_, > +Yocto_, > +CentOS_, > +and RHEL_. > + > +.. _Debian: https://www.debian.org/releases/ > +.. _Ubuntu: https://wiki.ubuntu.com/Releases > +.. _OpenSUSE: https://en.opensuse.org/Lifetime > +.. _SLES: https://www.suse.com/lifecycle/ > +.. _Yocto: https://wiki.yoctoproject.org/wiki/Releases > +.. _CentOS: https://wiki.centos.org/About/Product > +.. _RHEL: https://access.redhat.com/support/policy/updates/errata > + > +Specific distro versions supported in this release > +-------------------------------------------------- > + > +======== ================== > +Distro Supported releases > +======== ================== > +Debian 10 (Buster) > +Ubuntu 20.10 (Groovy Gorilla), 20.04 (Focal Fossa), 18.04 (Bionic Beaver), 16.04 (Xenial Xerus) > +OpenSUSE Leap 15.2 > +SLES SLES 11, 12, 15 > +Yocto 3.1 (Dunfell) Yocto only supports one version of Xen (as there is usually only one xen recipe per yocto version) which can make the version here a bit tricky: Yocto 3.1 (Dunfell) supports only Xen 4.12 Yocto 3.2 (Gategarth) support only Xen 4.14 but has a Yocto master recipe which should actually be used by someone who would want to try Xen master. So I would suggest to put Yocto 3.2 here only. @Christopher: what is your view here ? Cheers Bertrand > +CentOS 8 > +RHEL 8 > +======== ================== > + > +.. note:: > + > + We also support Arch Linux, but as it's a rolling distribution, the > + concept of "security supported releases" doesn't really apply. > -- > 2.25.1 > >
> On Oct 1, 2020, at 1:58 PM, Andrew Cooper <Andrew.Cooper3@citrix.com> wrote: > > On 30/09/2020 13:57, George Dunlap wrote: >> Define a specific criteria for how we determine what tools and >> libraries to be compatible with. This will clarify issues such as, >> "Should we continue to support Python 2.4" moving forward. > > Luckily that one is settled. Arguably a better option might be "what is > the minimum toolchain to support" ? > >> Note that CentOS 7 is set to stop receiving "normal" maintenance >> updates in "Q4 2020"; assuming that 4.15 is released after that, we >> only need to support CentOS / RHEL 8. > > While I appreciate that this doesn't mean "we'll break CentOS 7 in Q4", > I'm going to have some substantial development issues if C7 actually > stops working, at least in the short to medium term. You’re going to have development issues in the short-to-medium term as C7 stops getting bug-fixes anyway. I’m pretty sure you already re-compile your own versions of a lot of the toolchains and libraries; if you stay on C7 you’ll just have to add things in one by one (or use updated versions from EPEL) as things come up. >> Signed-off-by: George Dunlap <george.dunlap@citrix.com> >> --- >> >> CC: Ian Jackson <ian.jackson@citrix.com> >> CC: Wei Liu <wl@xen.org> >> CC: Andrew Cooper <andrew.cooper3@citrix.com> >> CC: Jan Beulich <jbeulich@suse.com> >> CC: Stefano Stabellini <sstabellini@kernel.org> >> CC: Julien Grall <julien@xen.org> >> CC: Rich Persaud <persaur@gmail.com> >> CC: Bertrand Marquis <Bertrand.Marquis@arm.com> >> --- >> docs/index.rst | 2 + >> docs/policies/dependency-versions.rst | 76 +++++++++++++++++++++++++++ >> 2 files changed, 78 insertions(+) >> create mode 100644 docs/policies/dependency-versions.rst >> >> diff --git a/docs/index.rst b/docs/index.rst >> index b75487a05d..ac175eacc8 100644 >> --- a/docs/index.rst >> +++ b/docs/index.rst >> @@ -57,5 +57,7 @@ Miscellanea >> ----------- >> >> .. toctree:: >> + :maxdepth: 1 >> >> + policies/dependency-versions > > I think it is great that this is going into Sphinx. > > However, I'd prefer to avoid proliferating random things at the top > level, to try and keep everything in a coherent structure. I was hoping for your feedback on where to put this. :-) > For better or worse, I guestimated at "admin guide" (end user and > sysadmin guide), "guest docs" (VM ABI, and guest kernel developers), and > "hypervisors docs" (hacking Xen). Is “hypervisor” in this sense meant to mean the actual hypervisor (xen.git/xen), or the whole hypervisor system (i.e., everything in xen.git)? It seems to me that we need something like the latter; in which case maybe we should change that section to “developer documentation” or something, with “hypervisor” as a section under that? > I'm happy to shuffle the dividing lines if a better arrangement becomes > obvious. This particular doc logically lives with "building Xen from > source". I don’t see a “building Xen from source” section (except for Hypervisor Documentation/Code Coverage/Compiling Xen, which is obviously specific to code coverage). If the main target of the page is to tell admins / downstreams what distros we support, then it might go under “Admin Guide” somewhere. If the main target is to tell developers what versions they have to support / don’t have to support, then putting it under a newly-created “developer documentation” section would probably make the most sense. I think I’d go with the latter, if you’re OK with it. >> glossary >> diff --git a/docs/policies/dependency-versions.rst b/docs/policies/dependency-versions.rst >> new file mode 100644 >> index 0000000000..d5eeb848d8 >> --- /dev/null >> +++ b/docs/policies/dependency-versions.rst >> @@ -0,0 +1,76 @@ >> +.. SPDX-License-Identifier: CC-BY-4.0 >> + >> +Build and runtime dependencies >> +============================== >> + >> +Xen depends on other programs and libraries to build and to run. >> +Chosing a minimum version of these tools to support requires a careful >> +balance: Supporting older versions of these tools or libraries means >> +that Xen can compile on a wider variety of systems; but means that Xen >> +cannot take advantage of features available in newer versions. >> +Conversely, requiring newer versions means that Xen can take advantage >> +of newer features, but cannot work on as wide a variety of systems. >> + >> +Specific dependencies and versions for a given Xen release will be >> +listed in the toplevel README, and/or specified by the ``configure`` >> +system. This document lays out the principles by which those versions >> +should be chosen. >> + >> +The general principle is this: >> + >> + Xen should build on currently-supported versions of major distros >> + when released. >> + >> +"Currently-supported" means whatever that distro's version of "full >> +support". For instance, at the time of writing, CentOS 7 and 8 are >> +listed as being given "Full Updates", but CentOS 6 is listed as >> +"Maintenance updates"; under this criterium, we would try to ensure >> +that Xen could build on CentOS 7 and 8, but not on CentOS 6. >> + >> +Exceptions for specific distros or tools may be made when appropriate. >> + >> +One exception to this is compiler versions for the hypervisor. >> +Support for new instructions, and in particular support for new safety >> +features, may require a newer compiler than many distros support. >> +These will be specified in the README. > > The problem we have is that xen.git contains two very different things. > There is the hypervisor itself, which is embedded, and can easily be > cross compiled, and there is the content of tools/ which depends on a > lot of distro infrastructure. > > We expect tools/ to work in any supported distro, without having to do > weird toolchain gymnastics. > > For xen/ at the moment we have a very obsolete toolchain requirements, > and this is holding us back in some areas. We're looking to bring that > forward, and may consider that being newer than some of the old distros > is necessary. > > At the moment however, we have quite a lot of functionality which is > dependent on being able to detect suitable toolchain. GCOV and CET-SS > are examples. These features will turn themselves off in older distros, > so while you can "build" Xen that far back, you might not get everything. > > For CET in particular, there is no feasible way to support it on older > toolchains. (unless someone comes up with an extremely convincing way > of hand-crafting memory operands using raw .byte's in inline assembler.) > > I definitely don't think it is unreasonable for us to require the use of > (potentially) bleeding edge toolchains if they want to use (potentially) > bleeding edge features. CET-SS isn't bleeding edge any more, but > CET-IBT is due to the additional linker work required to make it > function. A future one which we need to do something about is Control > Flow Integrity, which is Clang specific, depends on LTO, and caused > Linux to up their minimum supported version to 10.0.1 which was when all > the bugfixes got merged. You seem to be explaining why I wrote this paragraph. Did you have any specific changes you wanted to make? :-) >> + >> +Distros we consider when deciding minimum versions >> +-------------------------------------------------- >> + >> +We currently aim to support Xen building and running on the following distributions: >> +Debian_, >> +Ubuntu_, >> +OpenSUSE_, >> +Arch Linux, > > No link for Arch? The link points to the page describing the release lifecycles; Arch doesn’t really have that concept (as noted in the next section). I could make it so that links to the release lifecycle page is in the table below instead. > >> +SLES_, >> +Yocto_, >> +CentOS_, >> +and RHEL_. >> + >> +.. _Debian: https://www.debian.org/releases/ >> +.. _Ubuntu: https://wiki.ubuntu.com/Releases >> +.. _OpenSUSE: https://en.opensuse.org/Lifetime >> +.. _SLES: https://www.suse.com/lifecycle/ >> +.. _Yocto: https://wiki.yoctoproject.org/wiki/Releases >> +.. _CentOS: https://wiki.centos.org/About/Product >> +.. _RHEL: https://access.redhat.com/support/policy/updates/errata >> + >> +Specific distro versions supported in this release >> +-------------------------------------------------- >> + >> +======== ================== >> +Distro Supported releases >> +======== ================== >> +Debian 10 (Buster) >> +Ubuntu 20.10 (Groovy Gorilla), 20.04 (Focal Fossa), 18.04 (Bionic Beaver), 16.04 (Xenial Xerus) >> +OpenSUSE Leap 15.2 >> +SLES SLES 11, 12, 15 >> +Yocto 3.1 (Dunfell) >> +CentOS 8 >> +RHEL 8 >> +======== ================== > > How about a 3rd column for "supported until" ? It would stop this page > becoming stale simply over time. If we did that, it would make the table longer, as we’d have a separate row for each distro release rather than each distro. The release manager needs to look at this table before the release; for that they’ll have to go to the release lifecycle page of the various distros anyway, to pick up new versions of the distro. So I don’t think having the date here adds that much. > >> + >> +.. note:: >> + >> + We also support Arch Linux, but as it's a rolling distribution, the >> + concept of "security supported releases" doesn't really apply. > > Should we rationalise this list with the docker containers? We definitely should. For distros for which we can’t get docker containers in the gitlab CI (e.g., SLES, RHEL), maybe we could consider requiring a “maintainer” to step up and be responsible for testing them before each release. -George
On Wed, Sep 30, 2020 at 01:57:36PM +0100, George Dunlap wrote: > Define a specific criteria for how we determine what tools and > libraries to be compatible with. This will clarify issues such as, > "Should we continue to support Python 2.4" moving forward. > > Note that CentOS 7 is set to stop receiving "normal" maintenance > updates in "Q4 2020"; assuming that 4.15 is released after that, we > only need to support CentOS / RHEL 8. > > Signed-off-by: George Dunlap <george.dunlap@citrix.com> > --- > > CC: Ian Jackson <ian.jackson@citrix.com> > CC: Wei Liu <wl@xen.org> > CC: Andrew Cooper <andrew.cooper3@citrix.com> > CC: Jan Beulich <jbeulich@suse.com> > CC: Stefano Stabellini <sstabellini@kernel.org> > CC: Julien Grall <julien@xen.org> > CC: Rich Persaud <persaur@gmail.com> > CC: Bertrand Marquis <Bertrand.Marquis@arm.com> > --- > docs/index.rst | 2 + > docs/policies/dependency-versions.rst | 76 +++++++++++++++++++++++++++ > 2 files changed, 78 insertions(+) > create mode 100644 docs/policies/dependency-versions.rst > > diff --git a/docs/index.rst b/docs/index.rst > index b75487a05d..ac175eacc8 100644 > --- a/docs/index.rst > +++ b/docs/index.rst > @@ -57,5 +57,7 @@ Miscellanea > ----------- > > .. toctree:: > + :maxdepth: 1 > > + policies/dependency-versions > glossary > diff --git a/docs/policies/dependency-versions.rst b/docs/policies/dependency-versions.rst > new file mode 100644 > index 0000000000..d5eeb848d8 > --- /dev/null > +++ b/docs/policies/dependency-versions.rst > @@ -0,0 +1,76 @@ > +.. SPDX-License-Identifier: CC-BY-4.0 > + > +Build and runtime dependencies > +============================== > + > +Xen depends on other programs and libraries to build and to run. > +Chosing a minimum version of these tools to support requires a careful > +balance: Supporting older versions of these tools or libraries means > +that Xen can compile on a wider variety of systems; but means that Xen > +cannot take advantage of features available in newer versions. > +Conversely, requiring newer versions means that Xen can take advantage > +of newer features, but cannot work on as wide a variety of systems. > + > +Specific dependencies and versions for a given Xen release will be > +listed in the toplevel README, and/or specified by the ``configure`` > +system. This document lays out the principles by which those versions > +should be chosen. > + > +The general principle is this: > + > + Xen should build on currently-supported versions of major distros > + when released. > + > +"Currently-supported" means whatever that distro's version of "full > +support". For instance, at the time of writing, CentOS 7 and 8 are > +listed as being given "Full Updates", but CentOS 6 is listed as > +"Maintenance updates"; under this criterium, we would try to ensure > +that Xen could build on CentOS 7 and 8, but not on CentOS 6. > + > +Exceptions for specific distros or tools may be made when appropriate. > + > +One exception to this is compiler versions for the hypervisor. > +Support for new instructions, and in particular support for new safety > +features, may require a newer compiler than many distros support. > +These will be specified in the README. > + > +Distros we consider when deciding minimum versions > +-------------------------------------------------- > + > +We currently aim to support Xen building and running on the following distributions: > +Debian_, > +Ubuntu_, > +OpenSUSE_, > +Arch Linux, > +SLES_, > +Yocto_, > +CentOS_, > +and RHEL_. Could we add FreeBSD here, I've been packaging Xen there for quite some time now, and try to keep it working. It's an interesting target because it has quite a different toolchain as it's fully llvm based (clang + lld) and then it's using the ELF Toolchain. https://www.freebsd.org/releases/ Not sure if we want to rename the current section to Linux distros and add a different one for other OSes. Thanks, Roger.
On Thu, 1 Oct 2020, George Dunlap wrote: > > On Sep 30, 2020, at 9:23 PM, Stefano Stabellini <sstabellini@kernel.org> wrote: > > > > On Wed, 30 Sep 2020, George Dunlap wrote: > >> Define a specific criteria for how we determine what tools and > >> libraries to be compatible with. This will clarify issues such as, > >> "Should we continue to support Python 2.4" moving forward. > >> > >> Note that CentOS 7 is set to stop receiving "normal" maintenance > >> updates in "Q4 2020"; assuming that 4.15 is released after that, we > >> only need to support CentOS / RHEL 8. > >> > >> Signed-off-by: George Dunlap <george.dunlap@citrix.com> > >> --- > >> > >> CC: Ian Jackson <ian.jackson@citrix.com> > >> CC: Wei Liu <wl@xen.org> > >> CC: Andrew Cooper <andrew.cooper3@citrix.com> > >> CC: Jan Beulich <jbeulich@suse.com> > >> CC: Stefano Stabellini <sstabellini@kernel.org> > >> CC: Julien Grall <julien@xen.org> > >> CC: Rich Persaud <persaur@gmail.com> > >> CC: Bertrand Marquis <Bertrand.Marquis@arm.com> > >> --- > >> docs/index.rst | 2 + > >> docs/policies/dependency-versions.rst | 76 +++++++++++++++++++++++++++ > >> 2 files changed, 78 insertions(+) > >> create mode 100644 docs/policies/dependency-versions.rst > >> > >> diff --git a/docs/index.rst b/docs/index.rst > >> index b75487a05d..ac175eacc8 100644 > >> --- a/docs/index.rst > >> +++ b/docs/index.rst > >> @@ -57,5 +57,7 @@ Miscellanea > >> ----------- > >> > >> .. toctree:: > >> + :maxdepth: 1 > >> > >> + policies/dependency-versions > >> glossary > >> diff --git a/docs/policies/dependency-versions.rst b/docs/policies/dependency-versions.rst > >> new file mode 100644 > >> index 0000000000..d5eeb848d8 > >> --- /dev/null > >> +++ b/docs/policies/dependency-versions.rst > >> @@ -0,0 +1,76 @@ > >> +.. SPDX-License-Identifier: CC-BY-4.0 > >> + > >> +Build and runtime dependencies > >> +============================== > >> + > >> +Xen depends on other programs and libraries to build and to run. > >> +Chosing a minimum version of these tools to support requires a careful > >> +balance: Supporting older versions of these tools or libraries means > >> +that Xen can compile on a wider variety of systems; but means that Xen > >> +cannot take advantage of features available in newer versions. > >> +Conversely, requiring newer versions means that Xen can take advantage > >> +of newer features, but cannot work on as wide a variety of systems. > >> + > >> +Specific dependencies and versions for a given Xen release will be > >> +listed in the toplevel README, and/or specified by the ``configure`` > >> +system. This document lays out the principles by which those versions > >> +should be chosen. > >> + > >> +The general principle is this: > >> + > >> + Xen should build on currently-supported versions of major distros > >> + when released. > >> + > >> +"Currently-supported" means whatever that distro's version of "full > >> +support". For instance, at the time of writing, CentOS 7 and 8 are > >> +listed as being given "Full Updates", but CentOS 6 is listed as > >> +"Maintenance updates"; under this criterium, we would try to ensure > >> +that Xen could build on CentOS 7 and 8, but not on CentOS 6. > >> + > >> +Exceptions for specific distros or tools may be made when appropriate. > >> + > >> +One exception to this is compiler versions for the hypervisor. > >> +Support for new instructions, and in particular support for new safety > >> +features, may require a newer compiler than many distros support. > >> +These will be specified in the README. > >> + > >> +Distros we consider when deciding minimum versions > >> +-------------------------------------------------- > >> + > >> +We currently aim to support Xen building and running on the following distributions: > >> +Debian_, > >> +Ubuntu_, > >> +OpenSUSE_, > >> +Arch Linux, > >> +SLES_, > >> +Yocto_, > >> +CentOS_, > >> +and RHEL_. > > > > Alpine Linux should be in the list (consider its usage in container > > environment.) > > Sure, we can add that one in. Although, we might consider requiring that distros on this list be first be added to the Gitlab CI loop if possible. > > > I am still on Alpine Linux 3.7, so I am sure that one works. Probably > > other versions work too. > > Right, but the question is, if someone posts a patch which causes it to no longer build on 3.7, would we reject it or accept it? > > According to https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases, only 3.12 is currently receiving bug fixes; so by the criteria above, we would only reject a changeset if it caused a build regression for 3.12. > > I would argue that this is the right approach: It doesn’t make sense for us to spend more effort keeping an old distro working than that community it self spends keeping it working. The Ubuntu community spends effort keeping Ubuntu 16.04 in working shape, so it makes sense for us to spend effort making sure Xen 4.15 builds and runs on it. The Alpine Linux community doesn’t promise to spend any effort to fix any more bugs in Alpine Linux 3.11, so it doesn’t make any sense for us to spend effort making sure Xen 4.15 runs on it. > > Obviously if it builds on Ubuntu 16.04 there’s a pretty high probability that it will also build on Alpine Linux 3.4+ (released around the same time); we just don’t want to promise that. OK
On Thu, Oct 1, 2020 at 7:38 AM Bertrand Marquis <Bertrand.Marquis@arm.com> wrote: > > Hi George, > > + Christopher Clark to have his view on what to put for Yocto. > > > On 30 Sep 2020, at 13:57, George Dunlap <george.dunlap@citrix.com> wrote: > > > > Define a specific criteria for how we determine what tools and > > libraries to be compatible with. This will clarify issues such as, > > "Should we continue to support Python 2.4" moving forward. > > > > Note that CentOS 7 is set to stop receiving "normal" maintenance > > updates in "Q4 2020"; assuming that 4.15 is released after that, we > > only need to support CentOS / RHEL 8. > > > > Signed-off-by: George Dunlap <george.dunlap@citrix.com> > > --- > > > > CC: Ian Jackson <ian.jackson@citrix.com> > > CC: Wei Liu <wl@xen.org> > > CC: Andrew Cooper <andrew.cooper3@citrix.com> > > CC: Jan Beulich <jbeulich@suse.com> > > CC: Stefano Stabellini <sstabellini@kernel.org> > > CC: Julien Grall <julien@xen.org> > > CC: Rich Persaud <persaur@gmail.com> > > CC: Bertrand Marquis <Bertrand.Marquis@arm.com> > > --- > > docs/index.rst | 2 + > > docs/policies/dependency-versions.rst | 76 +++++++++++++++++++++++++++ > > 2 files changed, 78 insertions(+) > > create mode 100644 docs/policies/dependency-versions.rst > > > > diff --git a/docs/index.rst b/docs/index.rst > > index b75487a05d..ac175eacc8 100644 > > --- a/docs/index.rst > > +++ b/docs/index.rst > > @@ -57,5 +57,7 @@ Miscellanea > > ----------- > > > > .. toctree:: > > + :maxdepth: 1 > > > > + policies/dependency-versions > > glossary > > diff --git a/docs/policies/dependency-versions.rst b/docs/policies/dependency-versions.rst > > new file mode 100644 > > index 0000000000..d5eeb848d8 > > --- /dev/null > > +++ b/docs/policies/dependency-versions.rst > > @@ -0,0 +1,76 @@ > > +.. SPDX-License-Identifier: CC-BY-4.0 > > + > > +Build and runtime dependencies > > +============================== > > + > > +Xen depends on other programs and libraries to build and to run. > > +Chosing a minimum version of these tools to support requires a careful > > +balance: Supporting older versions of these tools or libraries means > > +that Xen can compile on a wider variety of systems; but means that Xen > > +cannot take advantage of features available in newer versions. > > +Conversely, requiring newer versions means that Xen can take advantage > > +of newer features, but cannot work on as wide a variety of systems. > > + > > +Specific dependencies and versions for a given Xen release will be > > +listed in the toplevel README, and/or specified by the ``configure`` > > +system. This document lays out the principles by which those versions > > +should be chosen. > > + > > +The general principle is this: > > + > > + Xen should build on currently-supported versions of major distros > > + when released. > > + > > +"Currently-supported" means whatever that distro's version of "full > > +support". For instance, at the time of writing, CentOS 7 and 8 are > > +listed as being given "Full Updates", but CentOS 6 is listed as > > +"Maintenance updates"; under this criterium, we would try to ensure > > +that Xen could build on CentOS 7 and 8, but not on CentOS 6. > > + > > +Exceptions for specific distros or tools may be made when appropriate. > > + > > +One exception to this is compiler versions for the hypervisor. > > +Support for new instructions, and in particular support for new safety > > +features, may require a newer compiler than many distros support. > > +These will be specified in the README. > > + > > +Distros we consider when deciding minimum versions > > +-------------------------------------------------- > > + > > +We currently aim to support Xen building and running on the following distributions: > > +Debian_, > > +Ubuntu_, > > +OpenSUSE_, > > +Arch Linux, > > +SLES_, > > +Yocto_, > > +CentOS_, > > +and RHEL_. > > + > > +.. _Debian: https://www.debian.org/releases/ > > +.. _Ubuntu: https://wiki.ubuntu.com/Releases > > +.. _OpenSUSE: https://en.opensuse.org/Lifetime > > +.. _SLES: https://www.suse.com/lifecycle/ > > +.. _Yocto: https://wiki.yoctoproject.org/wiki/Releases > > +.. _CentOS: https://wiki.centos.org/About/Product > > +.. _RHEL: https://access.redhat.com/support/policy/updates/errata > > + > > +Specific distro versions supported in this release > > +-------------------------------------------------- > > + > > +======== ================== > > +Distro Supported releases > > +======== ================== > > +Debian 10 (Buster) > > +Ubuntu 20.10 (Groovy Gorilla), 20.04 (Focal Fossa), 18.04 (Bionic Beaver), 16.04 (Xenial Xerus) > > +OpenSUSE Leap 15.2 > > +SLES SLES 11, 12, 15 > > +Yocto 3.1 (Dunfell) > > Yocto only supports one version of Xen (as there is usually only one xen recipe per yocto version) I'm not sure that's totally accurate: the Yocto Xen recipes are written to support backwards compatibility with older versions of Xen. In general, care and effort has been expended to support building with multiple versions of Xen with the same recipes, via variable override or bbappend, and it is expected to work. > which can make the version here a bit tricky: > Yocto 3.1 (Dunfell) supports only Xen 4.12 > Yocto 3.2 (Gategarth) support only Xen 4.14 but has a Yocto master recipe which should actually be used > by someone who would want to try Xen master. > > So I would suggest to put Yocto 3.2 here only. > > @Christopher: what is your view here ? Thanks for asking. I don't quite agree with that recommendation: I think Dunfell does belong, with an indication that it requires Gatesgarth meta-virtualization. Dunfell is the LTS release, so a compatibility statement about it is important. ie: Yocto 3.1 (Dunfell + Gatesgarth meta-virtualization) Effort has already been made within Yocto to make the Gatesgarth meta-virtualization layer compatible with Dunfell open-embedded core, specifically to allow newer Xen to be used with the LTS Dunfell software from the core layers. I would hope that any issues that are found with that configuration will be posted so they can be fixed. thanks, Christopher > > Cheers > Bertrand > > > +CentOS 8 > > +RHEL 8 > > +======== ================== > > + > > +.. note:: > > + > > + We also support Arch Linux, but as it's a rolling distribution, the > > + concept of "security supported releases" doesn't really apply. > > -- > > 2.25.1 > > > > >
> On Oct 1, 2020, at 4:36 PM, Roger Pau Monne <roger.pau@citrix.com> wrote: > > On Wed, Sep 30, 2020 at 01:57:36PM +0100, George Dunlap wrote: >> + >> +Distros we consider when deciding minimum versions >> +-------------------------------------------------- >> + >> +We currently aim to support Xen building and running on the following distributions: >> +Debian_, >> +Ubuntu_, >> +OpenSUSE_, >> +Arch Linux, >> +SLES_, >> +Yocto_, >> +CentOS_, >> +and RHEL_. > > Could we add FreeBSD here, I've been packaging Xen there for quite > some time now, and try to keep it working. Oh, yes of course. And probably NetBSD as well. > It's an interesting target because it has quite a different toolchain > as it's fully llvm based (clang + lld) and then it's using the ELF > Toolchain. > > https://www.freebsd.org/releases/ > > Not sure if we want to rename the current section to Linux distros and > add a different one for other OSes. I don’t think it makes sense to list these separately. I’ll try to make sure the naming encompasses both. -George
Hi Christopher, > On 2 Oct 2020, at 07:25, Christopher Clark <christopher.w.clark@gmail.com> wrote: > > On Thu, Oct 1, 2020 at 7:38 AM Bertrand Marquis > <Bertrand.Marquis@arm.com> wrote: >> >> Hi George, >> >> + Christopher Clark to have his view on what to put for Yocto. >> >>> On 30 Sep 2020, at 13:57, George Dunlap <george.dunlap@citrix.com> wrote: >>> >>> Define a specific criteria for how we determine what tools and >>> libraries to be compatible with. This will clarify issues such as, >>> "Should we continue to support Python 2.4" moving forward. >>> >>> Note that CentOS 7 is set to stop receiving "normal" maintenance >>> updates in "Q4 2020"; assuming that 4.15 is released after that, we >>> only need to support CentOS / RHEL 8. >>> >>> Signed-off-by: George Dunlap <george.dunlap@citrix.com> >>> --- >>> >>> CC: Ian Jackson <ian.jackson@citrix.com> >>> CC: Wei Liu <wl@xen.org> >>> CC: Andrew Cooper <andrew.cooper3@citrix.com> >>> CC: Jan Beulich <jbeulich@suse.com> >>> CC: Stefano Stabellini <sstabellini@kernel.org> >>> CC: Julien Grall <julien@xen.org> >>> CC: Rich Persaud <persaur@gmail.com> >>> CC: Bertrand Marquis <Bertrand.Marquis@arm.com> >>> --- >>> docs/index.rst | 2 + >>> docs/policies/dependency-versions.rst | 76 +++++++++++++++++++++++++++ >>> 2 files changed, 78 insertions(+) >>> create mode 100644 docs/policies/dependency-versions.rst >>> >>> diff --git a/docs/index.rst b/docs/index.rst >>> index b75487a05d..ac175eacc8 100644 >>> --- a/docs/index.rst >>> +++ b/docs/index.rst >>> @@ -57,5 +57,7 @@ Miscellanea >>> ----------- >>> >>> .. toctree:: >>> + :maxdepth: 1 >>> >>> + policies/dependency-versions >>> glossary >>> diff --git a/docs/policies/dependency-versions.rst b/docs/policies/dependency-versions.rst >>> new file mode 100644 >>> index 0000000000..d5eeb848d8 >>> --- /dev/null >>> +++ b/docs/policies/dependency-versions.rst >>> @@ -0,0 +1,76 @@ >>> +.. SPDX-License-Identifier: CC-BY-4.0 >>> + >>> +Build and runtime dependencies >>> +============================== >>> + >>> +Xen depends on other programs and libraries to build and to run. >>> +Chosing a minimum version of these tools to support requires a careful >>> +balance: Supporting older versions of these tools or libraries means >>> +that Xen can compile on a wider variety of systems; but means that Xen >>> +cannot take advantage of features available in newer versions. >>> +Conversely, requiring newer versions means that Xen can take advantage >>> +of newer features, but cannot work on as wide a variety of systems. >>> + >>> +Specific dependencies and versions for a given Xen release will be >>> +listed in the toplevel README, and/or specified by the ``configure`` >>> +system. This document lays out the principles by which those versions >>> +should be chosen. >>> + >>> +The general principle is this: >>> + >>> + Xen should build on currently-supported versions of major distros >>> + when released. >>> + >>> +"Currently-supported" means whatever that distro's version of "full >>> +support". For instance, at the time of writing, CentOS 7 and 8 are >>> +listed as being given "Full Updates", but CentOS 6 is listed as >>> +"Maintenance updates"; under this criterium, we would try to ensure >>> +that Xen could build on CentOS 7 and 8, but not on CentOS 6. >>> + >>> +Exceptions for specific distros or tools may be made when appropriate. >>> + >>> +One exception to this is compiler versions for the hypervisor. >>> +Support for new instructions, and in particular support for new safety >>> +features, may require a newer compiler than many distros support. >>> +These will be specified in the README. >>> + >>> +Distros we consider when deciding minimum versions >>> +-------------------------------------------------- >>> + >>> +We currently aim to support Xen building and running on the following distributions: >>> +Debian_, >>> +Ubuntu_, >>> +OpenSUSE_, >>> +Arch Linux, >>> +SLES_, >>> +Yocto_, >>> +CentOS_, >>> +and RHEL_. >>> + >>> +.. _Debian: https://www.debian.org/releases/ >>> +.. _Ubuntu: https://wiki.ubuntu.com/Releases >>> +.. _OpenSUSE: https://en.opensuse.org/Lifetime >>> +.. _SLES: https://www.suse.com/lifecycle/ >>> +.. _Yocto: https://wiki.yoctoproject.org/wiki/Releases >>> +.. _CentOS: https://wiki.centos.org/About/Product >>> +.. _RHEL: https://access.redhat.com/support/policy/updates/errata >>> + >>> +Specific distro versions supported in this release >>> +-------------------------------------------------- >>> + >>> +======== ================== >>> +Distro Supported releases >>> +======== ================== >>> +Debian 10 (Buster) >>> +Ubuntu 20.10 (Groovy Gorilla), 20.04 (Focal Fossa), 18.04 (Bionic Beaver), 16.04 (Xenial Xerus) >>> +OpenSUSE Leap 15.2 >>> +SLES SLES 11, 12, 15 >>> +Yocto 3.1 (Dunfell) >> >> Yocto only supports one version of Xen (as there is usually only one xen recipe per yocto version) > > I'm not sure that's totally accurate: the Yocto Xen recipes are > written to support backwards compatibility with older versions of Xen. > In general, care and effort has been expended to support building with > multiple versions of Xen with the same recipes, via variable override > or bbappend, and it is expected to work. I agree when the latest version of meta-virtualization is used (at least for now). > >> which can make the version here a bit tricky: >> Yocto 3.1 (Dunfell) supports only Xen 4.12 >> Yocto 3.2 (Gategarth) support only Xen 4.14 but has a Yocto master recipe which should actually be used >> by someone who would want to try Xen master. >> >> So I would suggest to put Yocto 3.2 here only. >> >> @Christopher: what is your view here ? > > Thanks for asking. I don't quite agree with that recommendation: I > think Dunfell does belong, with an indication that it requires > Gatesgarth meta-virtualization. Dunfell is the LTS release, so a > compatibility statement about it is important. ie: > > Yocto 3.1 (Dunfell + Gatesgarth meta-virtualization) Agree this is what we should say and add: Yocto 3.2 (Gatesgarth) > > Effort has already been made within Yocto to make the Gatesgarth > meta-virtualization layer compatible with Dunfell open-embedded core, > specifically to allow newer Xen to be used with the LTS Dunfell > software from the core layers. I would hope that any issues that are > found with that configuration will be posted so they can be fixed. > I must admit i never tested the combination that way but I will check if such a scenario could be added to the tests we define internally at arm. Thanks for the answers Cheers Bertrand > thanks, > > Christopher > >> >> Cheers >> Bertrand >> >>> +CentOS 8 >>> +RHEL 8 >>> +======== ================== >>> + >>> +.. note:: >>> + >>> + We also support Arch Linux, but as it's a rolling distribution, the >>> + concept of "security supported releases" doesn't really apply. >>> -- >>> 2.25.1
On 01/10/2020 15:50, George Dunlap wrote: >>> Signed-off-by: George Dunlap <george.dunlap@citrix.com> >>> --- >>> >>> CC: Ian Jackson <ian.jackson@citrix.com> >>> CC: Wei Liu <wl@xen.org> >>> CC: Andrew Cooper <andrew.cooper3@citrix.com> >>> CC: Jan Beulich <jbeulich@suse.com> >>> CC: Stefano Stabellini <sstabellini@kernel.org> >>> CC: Julien Grall <julien@xen.org> >>> CC: Rich Persaud <persaur@gmail.com> >>> CC: Bertrand Marquis <Bertrand.Marquis@arm.com> >>> --- >>> docs/index.rst | 2 + >>> docs/policies/dependency-versions.rst | 76 +++++++++++++++++++++++++++ >>> 2 files changed, 78 insertions(+) >>> create mode 100644 docs/policies/dependency-versions.rst >>> >>> diff --git a/docs/index.rst b/docs/index.rst >>> index b75487a05d..ac175eacc8 100644 >>> --- a/docs/index.rst >>> +++ b/docs/index.rst >>> @@ -57,5 +57,7 @@ Miscellanea >>> ----------- >>> >>> .. toctree:: >>> + :maxdepth: 1 >>> >>> + policies/dependency-versions >> I think it is great that this is going into Sphinx. >> >> However, I'd prefer to avoid proliferating random things at the top >> level, to try and keep everything in a coherent structure. > I was hoping for your feedback on where to put this. :-) > >> For better or worse, I guestimated at "admin guide" (end user and >> sysadmin guide), "guest docs" (VM ABI, and guest kernel developers), and >> "hypervisors docs" (hacking Xen). > Is “hypervisor” in this sense meant to mean the actual hypervisor (xen.git/xen), or the whole hypervisor system (i.e., everything in xen.git)? "yes". If it seems like I'm making this up as I go along, then perhaps its because I am. > It seems to me that we need something like the latter; in which case maybe we should change that section to “developer documentation” or something, with “hypervisor” as a section under that? My gut feeling is that "developing the hypervisor" is different enough from "developing the toolstack" that there will be little overlap in content. > >> I'm happy to shuffle the dividing lines if a better arrangement becomes >> obvious. This particular doc logically lives with "building Xen from >> source". > I don’t see a “building Xen from source” section (except for Hypervisor Documentation/Code Coverage/Compiling Xen, which is obviously specific to code coverage). There isn't one yet. > If the main target of the page is to tell admins / downstreams what distros we support, then it might go under “Admin Guide” somewhere. If the main target is to tell developers what versions they have to support / don’t have to support, then putting it under a newly-created “developer documentation” section would probably make the most sense. > > I think I’d go with the latter, if you’re OK with it. I don't think this page is applicable to downstreams. They've already got packages and have figured out their own support. This is purely a statement of what we (upstream) expect/check, which will inform developers wishing to work on master. > > >>> glossary >>> diff --git a/docs/policies/dependency-versions.rst b/docs/policies/dependency-versions.rst >>> new file mode 100644 >>> index 0000000000..d5eeb848d8 >>> --- /dev/null >>> +++ b/docs/policies/dependency-versions.rst >>> @@ -0,0 +1,76 @@ >>> +.. SPDX-License-Identifier: CC-BY-4.0 >>> + >>> +Build and runtime dependencies >>> +============================== >>> + >>> +Xen depends on other programs and libraries to build and to run. >>> +Chosing a minimum version of these tools to support requires a careful >>> +balance: Supporting older versions of these tools or libraries means >>> +that Xen can compile on a wider variety of systems; but means that Xen >>> +cannot take advantage of features available in newer versions. >>> +Conversely, requiring newer versions means that Xen can take advantage >>> +of newer features, but cannot work on as wide a variety of systems. >>> + >>> +Specific dependencies and versions for a given Xen release will be >>> +listed in the toplevel README, and/or specified by the ``configure`` >>> +system. This document lays out the principles by which those versions >>> +should be chosen. >>> + >>> +The general principle is this: >>> + >>> + Xen should build on currently-supported versions of major distros >>> + when released. >>> + >>> +"Currently-supported" means whatever that distro's version of "full >>> +support". For instance, at the time of writing, CentOS 7 and 8 are >>> +listed as being given "Full Updates", but CentOS 6 is listed as >>> +"Maintenance updates"; under this criterium, we would try to ensure >>> +that Xen could build on CentOS 7 and 8, but not on CentOS 6. >>> + >>> +Exceptions for specific distros or tools may be made when appropriate. >>> + >>> +One exception to this is compiler versions for the hypervisor. >>> +Support for new instructions, and in particular support for new safety >>> +features, may require a newer compiler than many distros support. >>> +These will be specified in the README. >> The problem we have is that xen.git contains two very different things. >> There is the hypervisor itself, which is embedded, and can easily be >> cross compiled, and there is the content of tools/ which depends on a >> lot of distro infrastructure. >> >> We expect tools/ to work in any supported distro, without having to do >> weird toolchain gymnastics. >> >> For xen/ at the moment we have a very obsolete toolchain requirements, >> and this is holding us back in some areas. We're looking to bring that >> forward, and may consider that being newer than some of the old distros >> is necessary. >> >> At the moment however, we have quite a lot of functionality which is >> dependent on being able to detect suitable toolchain. GCOV and CET-SS >> are examples. These features will turn themselves off in older distros, >> so while you can "build" Xen that far back, you might not get everything. >> >> For CET in particular, there is no feasible way to support it on older >> toolchains. (unless someone comes up with an extremely convincing way >> of hand-crafting memory operands using raw .byte's in inline assembler.) >> >> I definitely don't think it is unreasonable for us to require the use of >> (potentially) bleeding edge toolchains if they want to use (potentially) >> bleeding edge features. CET-SS isn't bleeding edge any more, but >> CET-IBT is due to the additional linker work required to make it >> function. A future one which we need to do something about is Control >> Flow Integrity, which is Clang specific, depends on LTO, and caused >> Linux to up their minimum supported version to 10.0.1 which was when all >> the bugfixes got merged. > You seem to be explaining why I wrote this paragraph. Did you have any specific changes you wanted to make? :-) I don't think the paragraph as written gets this point across. Even from the first sentence, Xen (the hypervisor) doesn't depend on external libraries, whereas Xen (the content of xen.git) does. > >>> + >>> +Distros we consider when deciding minimum versions >>> +-------------------------------------------------- >>> + >>> +We currently aim to support Xen building and running on the following distributions: >>> +Debian_, >>> +Ubuntu_, >>> +OpenSUSE_, >>> +Arch Linux, >> No link for Arch? > The link points to the page describing the release lifecycles; Arch doesn’t really have that concept (as noted in the next section). > > I could make it so that links to the release lifecycle page is in the table below instead. > >>> +SLES_, >>> +Yocto_, >>> +CentOS_, >>> +and RHEL_. >>> + >>> +.. _Debian: https://www.debian.org/releases/ >>> +.. _Ubuntu: https://wiki.ubuntu.com/Releases >>> +.. _OpenSUSE: https://en.opensuse.org/Lifetime >>> +.. _SLES: https://www.suse.com/lifecycle/ >>> +.. _Yocto: https://wiki.yoctoproject.org/wiki/Releases >>> +.. _CentOS: https://wiki.centos.org/About/Product >>> +.. _RHEL: https://access.redhat.com/support/policy/updates/errata >>> + >>> +Specific distro versions supported in this release >>> +-------------------------------------------------- >>> + >>> +======== ================== >>> +Distro Supported releases >>> +======== ================== >>> +Debian 10 (Buster) >>> +Ubuntu 20.10 (Groovy Gorilla), 20.04 (Focal Fossa), 18.04 (Bionic Beaver), 16.04 (Xenial Xerus) >>> +OpenSUSE Leap 15.2 >>> +SLES SLES 11, 12, 15 >>> +Yocto 3.1 (Dunfell) >>> +CentOS 8 >>> +RHEL 8 >>> +======== ================== >> How about a 3rd column for "supported until" ? It would stop this page >> becoming stale simply over time. > If we did that, it would make the table longer, as we’d have a separate row for each distro release rather than each distro. > > The release manager needs to look at this table before the release; for that they’ll have to go to the release lifecycle page of the various distros anyway, to pick up new versions of the distro. So I don’t think having the date here adds that much. Irrespective of the content of the table, I'd recommend Sphinx's list-table construct (see the example docs/guest-guide/x86/hypercall-abi.rst). This is deliberately more amenable to diffing when changes are made. Also I need to refresh one of my patches to add another extension for hyperlinks. The table on its own isn't terribly helpful, and will go stale. The point of adding a 3rd column is so people don't have to click through onto every distro page to find out whether the content of this page is still correct. I'd also recommend merging the hyperlinks into the first column of the table as a more obvious place to have the links, rather than in a line of text. ~Andrew
diff --git a/docs/index.rst b/docs/index.rst index b75487a05d..ac175eacc8 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -57,5 +57,7 @@ Miscellanea ----------- .. toctree:: + :maxdepth: 1 + policies/dependency-versions glossary diff --git a/docs/policies/dependency-versions.rst b/docs/policies/dependency-versions.rst new file mode 100644 index 0000000000..d5eeb848d8 --- /dev/null +++ b/docs/policies/dependency-versions.rst @@ -0,0 +1,76 @@ +.. SPDX-License-Identifier: CC-BY-4.0 + +Build and runtime dependencies +============================== + +Xen depends on other programs and libraries to build and to run. +Chosing a minimum version of these tools to support requires a careful +balance: Supporting older versions of these tools or libraries means +that Xen can compile on a wider variety of systems; but means that Xen +cannot take advantage of features available in newer versions. +Conversely, requiring newer versions means that Xen can take advantage +of newer features, but cannot work on as wide a variety of systems. + +Specific dependencies and versions for a given Xen release will be +listed in the toplevel README, and/or specified by the ``configure`` +system. This document lays out the principles by which those versions +should be chosen. + +The general principle is this: + + Xen should build on currently-supported versions of major distros + when released. + +"Currently-supported" means whatever that distro's version of "full +support". For instance, at the time of writing, CentOS 7 and 8 are +listed as being given "Full Updates", but CentOS 6 is listed as +"Maintenance updates"; under this criterium, we would try to ensure +that Xen could build on CentOS 7 and 8, but not on CentOS 6. + +Exceptions for specific distros or tools may be made when appropriate. + +One exception to this is compiler versions for the hypervisor. +Support for new instructions, and in particular support for new safety +features, may require a newer compiler than many distros support. +These will be specified in the README. + +Distros we consider when deciding minimum versions +-------------------------------------------------- + +We currently aim to support Xen building and running on the following distributions: +Debian_, +Ubuntu_, +OpenSUSE_, +Arch Linux, +SLES_, +Yocto_, +CentOS_, +and RHEL_. + +.. _Debian: https://www.debian.org/releases/ +.. _Ubuntu: https://wiki.ubuntu.com/Releases +.. _OpenSUSE: https://en.opensuse.org/Lifetime +.. _SLES: https://www.suse.com/lifecycle/ +.. _Yocto: https://wiki.yoctoproject.org/wiki/Releases +.. _CentOS: https://wiki.centos.org/About/Product +.. _RHEL: https://access.redhat.com/support/policy/updates/errata + +Specific distro versions supported in this release +-------------------------------------------------- + +======== ================== +Distro Supported releases +======== ================== +Debian 10 (Buster) +Ubuntu 20.10 (Groovy Gorilla), 20.04 (Focal Fossa), 18.04 (Bionic Beaver), 16.04 (Xenial Xerus) +OpenSUSE Leap 15.2 +SLES SLES 11, 12, 15 +Yocto 3.1 (Dunfell) +CentOS 8 +RHEL 8 +======== ================== + +.. note:: + + We also support Arch Linux, but as it's a rolling distribution, the + concept of "security supported releases" doesn't really apply.
Define a specific criteria for how we determine what tools and libraries to be compatible with. This will clarify issues such as, "Should we continue to support Python 2.4" moving forward. Note that CentOS 7 is set to stop receiving "normal" maintenance updates in "Q4 2020"; assuming that 4.15 is released after that, we only need to support CentOS / RHEL 8. Signed-off-by: George Dunlap <george.dunlap@citrix.com> --- CC: Ian Jackson <ian.jackson@citrix.com> CC: Wei Liu <wl@xen.org> CC: Andrew Cooper <andrew.cooper3@citrix.com> CC: Jan Beulich <jbeulich@suse.com> CC: Stefano Stabellini <sstabellini@kernel.org> CC: Julien Grall <julien@xen.org> CC: Rich Persaud <persaur@gmail.com> CC: Bertrand Marquis <Bertrand.Marquis@arm.com> --- docs/index.rst | 2 + docs/policies/dependency-versions.rst | 76 +++++++++++++++++++++++++++ 2 files changed, 78 insertions(+) create mode 100644 docs/policies/dependency-versions.rst