Hi Christopher, > On 2 Oct 2020, at 07:25, Christopher Clark <christopher.w.cl...@gmail.com> > wrote: > > On Thu, Oct 1, 2020 at 7:38 AM Bertrand Marquis > <bertrand.marq...@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.dun...@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.dun...@citrix.com> >>> --- >>> >>> CC: Ian Jackson <ian.jack...@citrix.com> >>> CC: Wei Liu <w...@xen.org> >>> CC: Andrew Cooper <andrew.coop...@citrix.com> >>> CC: Jan Beulich <jbeul...@suse.com> >>> CC: Stefano Stabellini <sstabell...@kernel.org> >>> CC: Julien Grall <jul...@xen.org> >>> CC: Rich Persaud <pers...@gmail.com> >>> CC: Bertrand Marquis <bertrand.marq...@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
