| Message ID | ebaa05ded3cfddb1e3f7c87cd806b866312878fb.1708962629.git.oleksii.kurochko@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Enable build of full Xen for RISC-V | expand |
On 26.02.2024 18:39, Oleksii Kurochko wrote: > This patch doesn't represent a strict lower bound for GCC and > GNU Binutils; rather, these versions are specifically employed by > the Xen RISC-V container and are anticipated to undergo continuous > testing. Up and until that container would be updated to a newer gcc. I'm afraid I view this as too weak a criteria, but I'm also not meaning to stand in the way if somebody else wants to ack this patch in this form; my bare minimum requirement is now met. > --- a/README > +++ b/README > @@ -48,6 +48,15 @@ provided by your OS distributor: > - For ARM 64-bit: > - GCC 5.1 or later > - GNU Binutils 2.24 or later > + - For RISC-V 64-bit: > + - GCC 12.2 or later > + - GNU Binutils 2.39 or later > + This doesn't represent a strict lower bound for GCC and GNU Binutils; > + rather, these versions are specifically employed by the Xen RISC-V > + container and are anticipated to undergo continuous testing. As per above, I think here it really needs saying "at the time of writing" or recording a concrete date. Furthermore I expect "these versions" relates to the specifically named versions and particularly _not_ to "or later": With the criteria you apply, using later versions (or in fact any version other than the very specific ones used in the container) would be similarly untested. Much like x86 and Arm don't have the full range of permitted tool chain versions continuously tested. Plus don't forget that distros may apply their own selection of patches on top of what they take from upstream (and they may also take random snapshots rather than released versions). IOW it is hard for me to see why RISC-V needs stronger restrictions here than other architectures. It ought to be possible to determine a baseline version. Even if taking the desire to have "pause" available as a requirement, gas (and presumably gld) 2.36.1 would already suffice. Jan
On Tue, 2024-02-27 at 08:55 +0100, Jan Beulich wrote: > On 26.02.2024 18:39, Oleksii Kurochko wrote: > > This patch doesn't represent a strict lower bound for GCC and > > GNU Binutils; rather, these versions are specifically employed by > > the Xen RISC-V container and are anticipated to undergo continuous > > testing. > > Up and until that container would be updated to a newer gcc. I'm > afraid I view this as too weak a criteria, but I'm also not meaning > to > stand in the way if somebody else wants to ack this patch in this > form; > my bare minimum requirement is now met. > > > --- a/README > > +++ b/README > > @@ -48,6 +48,15 @@ provided by your OS distributor: > > - For ARM 64-bit: > > - GCC 5.1 or later > > - GNU Binutils 2.24 or later > > + - For RISC-V 64-bit: > > + - GCC 12.2 or later > > + - GNU Binutils 2.39 or later > > + This doesn't represent a strict lower bound for GCC and > > GNU Binutils; > > + rather, these versions are specifically employed by the > > Xen RISC-V > > + container and are anticipated to undergo continuous > > testing. > > As per above, I think here it really needs saying "at the time of > writing" > or recording a concrete date. Furthermore I expect "these versions" > relates > to the specifically named versions and particularly _not_ to "or > later": > With the criteria you apply, using later versions (or in fact any > version > other than the very specific ones used in the container) would be > similarly > untested. Much like x86 and Arm don't have the full range of > permitted > tool chain versions continuously tested. Plus don't forget that > distros may > apply their own selection of patches on top of what they take from > upstream > (and they may also take random snapshots rather than released > versions). > > IOW it is hard for me to see why RISC-V needs stronger restrictions > here > than other architectures. It ought to be possible to determine a > baseline > version. Even if taking the desire to have "pause" available as a > requirement, gas (and presumably gld) 2.36.1 would already suffice. I'll be happy to determine a baseline version and RISC-V doesn't need stronger restriction that why I wrote: "This patch doesn't represent a strict lower bound for GCC and GNU Binutils". Would it be good to use for GCC -> "12.2 or later" and for Binutils -> "2.36.1 or later"? I missed that I've pushed RISC-V contrainer without fixing version of archlinux, so you are right that after container update what I wrote won't be true, as compiler version might be changed. Just for clarifying when the version will be agreed, does it mean that I should use a toolchain with mentioned version in this file and each time to verify that everything still working with this versions? ~ Oleksii
Hi Jan, On 27/02/2024 07:55, Jan Beulich wrote: > On 26.02.2024 18:39, Oleksii Kurochko wrote: >> This patch doesn't represent a strict lower bound for GCC and >> GNU Binutils; rather, these versions are specifically employed by >> the Xen RISC-V container and are anticipated to undergo continuous >> testing. > > Up and until that container would be updated to a newer gcc. I'm > afraid I view this as too weak a criteria, I disagree. We have to decide a limit at some point. It is sensible to say that we are only supporting what we can tests. AFAIK, this is what QEMU has been doing. > but I'm also not meaning to > stand in the way if somebody else wants to ack this patch in this form; > my bare minimum requirement is now met. > >> --- a/README >> +++ b/README >> @@ -48,6 +48,15 @@ provided by your OS distributor: >> - For ARM 64-bit: >> - GCC 5.1 or later >> - GNU Binutils 2.24 or later >> + - For RISC-V 64-bit: >> + - GCC 12.2 or later >> + - GNU Binutils 2.39 or later >> + This doesn't represent a strict lower bound for GCC and GNU Binutils; >> + rather, these versions are specifically employed by the Xen RISC-V >> + container and are anticipated to undergo continuous testing. > > As per above, I think here it really needs saying "at the time of writing" > or recording a concrete date. Furthermore I expect "these versions" relates > to the specifically named versions and particularly _not_ to "or later": > With the criteria you apply, using later versions (or in fact any version > other than the very specific ones used in the container) would be similarly > untested. Much like x86 and Arm don't have the full range of permitted > tool chain versions continuously tested. Plus don't forget that distros may > apply their own selection of patches on top of what they take from upstream > (and they may also take random snapshots rather than released versions). TBH, I think this should be dropped from the README. With the wording, it implies that older GCC would work, but this is not a guarantee. The same for Arm, I suspect some revision of GCC below 5.1 that may work. But that's just convenience to list a lower limit. With the sentence dropped, I would be happy to ack this patch. > > IOW it is hard for me to see why RISC-V needs stronger restrictions here > than other architectures. It ought to be possible to determine a baseline > version. Even if taking the desire to have "pause" available as a > requirement, gas (and presumably gld) 2.36.1 would already suffice. I think we want to bump it on Arm. There are zero reasons to try to keep a lower versions if nobody tests/use it in production. I would suggest to do the same on x86. What's the point of try to support Xen with a 15+ years old compiler? Cheers,
On 28/02/2024 10:58 pm, Julien Grall wrote: > Hi Jan, > > On 27/02/2024 07:55, Jan Beulich wrote: >> On 26.02.2024 18:39, Oleksii Kurochko wrote: >>> This patch doesn't represent a strict lower bound for GCC and >>> GNU Binutils; rather, these versions are specifically employed by >>> the Xen RISC-V container and are anticipated to undergo continuous >>> testing. >> >> Up and until that container would be updated to a newer gcc. I'm >> afraid I view this as too weak a criteria, > > I disagree. We have to decide a limit at some point. It is sensible to > say that we are only supporting what we can tests. AFAIK, this is what > QEMU has been doing. > >> but I'm also not meaning to >> stand in the way if somebody else wants to ack this patch in this form; >> my bare minimum requirement is now met. >> >>> --- a/README >>> +++ b/README >>> @@ -48,6 +48,15 @@ provided by your OS distributor: >>> - For ARM 64-bit: >>> - GCC 5.1 or later >>> - GNU Binutils 2.24 or later >>> + - For RISC-V 64-bit: >>> + - GCC 12.2 or later >>> + - GNU Binutils 2.39 or later >>> + This doesn't represent a strict lower bound for GCC and GNU >>> Binutils; >>> + rather, these versions are specifically employed by the Xen >>> RISC-V >>> + container and are anticipated to undergo continuous testing. >> >> As per above, I think here it really needs saying "at the time of >> writing" >> or recording a concrete date. Furthermore I expect "these versions" >> relates >> to the specifically named versions and particularly _not_ to "or later": >> With the criteria you apply, using later versions (or in fact any >> version >> other than the very specific ones used in the container) would be >> similarly >> untested. Much like x86 and Arm don't have the full range of permitted >> tool chain versions continuously tested. Plus don't forget that >> distros may >> apply their own selection of patches on top of what they take from >> upstream >> (and they may also take random snapshots rather than released versions). > > TBH, I think this should be dropped from the README. With the wording, > it implies that older GCC would work, but this is not a guarantee. > > The same for Arm, I suspect some revision of GCC below 5.1 that may > work. But that's just convenience to list a lower limit. > > With the sentence dropped, I would be happy to ack this patch. > >> >> IOW it is hard for me to see why RISC-V needs stronger restrictions here >> than other architectures. It ought to be possible to determine a >> baseline >> version. Even if taking the desire to have "pause" available as a >> requirement, gas (and presumably gld) 2.36.1 would already suffice. > > I think we want to bump it on Arm. There are zero reasons to try to > keep a lower versions if nobody tests/use it in production. > > I would suggest to do the same on x86. What's the point of try to > support Xen with a 15+ years old compiler? There is a material cost to supporting ancient toolchains. I'm increasingly unwilling to keep paying. I'm also bored of needing to support versions of binutils which don't know the Virt instructions, which are approaching 2 decades old now. There are very good reasons to move to GCC 5.1 minimum across the board, because that gets us several features (__has_include(), asm goto and _Generic()) which will make material improvements to our code. And I'd like to start using other bits of C11/gnu11. The choice of minimum toolchains should definitely be per-arch, and "this is the oldest one we regularly test" is an entirely fine reason to set the minimum bar. Furthermore, Linux has regularly been bumping minimum toolchain versions due to code generation issues, and we'd be foolish not pay attention. ~Andrew
On 28.02.2024 23:58, Julien Grall wrote: > On 27/02/2024 07:55, Jan Beulich wrote: >> On 26.02.2024 18:39, Oleksii Kurochko wrote: >>> This patch doesn't represent a strict lower bound for GCC and >>> GNU Binutils; rather, these versions are specifically employed by >>> the Xen RISC-V container and are anticipated to undergo continuous >>> testing. >> >> Up and until that container would be updated to a newer gcc. I'm >> afraid I view this as too weak a criteria, > > I disagree. We have to decide a limit at some point. It is sensible to > say that we are only supporting what we can tests. AFAIK, this is what > QEMU has been doing. I view qemu as a particularly bad example. They raise their baselines far too aggressively for my taste. >> IOW it is hard for me to see why RISC-V needs stronger restrictions here >> than other architectures. It ought to be possible to determine a baseline >> version. Even if taking the desire to have "pause" available as a >> requirement, gas (and presumably gld) 2.36.1 would already suffice. > > I think we want to bump it on Arm. There are zero reasons to try to keep > a lower versions if nobody tests/use it in production. > > I would suggest to do the same on x86. What's the point of try to > support Xen with a 15+ years old compiler? It could have long been bumped if only a proper scheme to follow for this and future bumping would have been put forward by anyone keen on such bumping, like - see his reply - e.g. Andrew. You may recall that this was discussed more than once on meetings, with no real outcome. I'm personally not meaning to stand in the way of such bumping as long as it's done in a predictable manner, but I'm not keen on doing so and hence I don't view it as my obligation to try to invent a reasonable scheme. (My personal view is that basic functionality should be possible to have virtually everywhere, whereas for advanced stuff it is fine to require a more modern tool chain.) The one additional concern I've raised in the past is that in the end it's not just minimal tool chain versions we rely on, but also other core system tools (see the recent move from "which" to "command -v" for an example of such a dependency, where luckily it turned out to not be an issue that the -v had only become a standard thing at some point). While for the tool chain I can arrange for making newer versions available, for core system tools I can't. Therefore being too eager there would mean I can't really / easily (smoke) test Xen anymore on ancient hardware every once in a while. When afaict we do too little of such testing already anyway, despite not having any lower bound on hardware that formally we support running Xen on. (And no, upgrading the ancient distros on that ancient hardware is not an option for me.) Jan
On 29/02/2024 07:58, Jan Beulich wrote: > On 28.02.2024 23:58, Julien Grall wrote: >> On 27/02/2024 07:55, Jan Beulich wrote: >>> On 26.02.2024 18:39, Oleksii Kurochko wrote: >>>> This patch doesn't represent a strict lower bound for GCC and >>>> GNU Binutils; rather, these versions are specifically employed by >>>> the Xen RISC-V container and are anticipated to undergo continuous >>>> testing. >>> >>> Up and until that container would be updated to a newer gcc. I'm >>> afraid I view this as too weak a criteria, >> >> I disagree. We have to decide a limit at some point. It is sensible to >> say that we are only supporting what we can tests. AFAIK, this is what >> QEMU has been doing. > > I view qemu as a particularly bad example. They raise their baselines > far too aggressively for my taste. AFAICT, the decision was based on the supported distros at the time. Which makes sense to me (even though I got recently caught because of this check). They also seem to be open to relax the check if there are any use cases. Why would we want to support build Xen on non-supported distros? > >>> IOW it is hard for me to see why RISC-V needs stronger restrictions here >>> than other architectures. It ought to be possible to determine a baseline >>> version. Even if taking the desire to have "pause" available as a >>> requirement, gas (and presumably gld) 2.36.1 would already suffice. >> >> I think we want to bump it on Arm. There are zero reasons to try to keep >> a lower versions if nobody tests/use it in production. >> >> I would suggest to do the same on x86. What's the point of try to >> support Xen with a 15+ years old compiler? > > It could have long been bumped if only a proper scheme to follow for > this and future bumping would have been put forward by anyone keen on > such bumping, like - see his reply - e.g. Andrew. You may recall that > this was discussed more than once on meetings, with no real outcome. > I'm personally not meaning to stand in the way of such bumping as long > as it's done in a predictable manner, but I'm not keen on doing so and > hence I don't view it as my obligation to try to invent a reasonable > scheme. (My personal view is that basic functionality should be > possible to have virtually everywhere, whereas for advanced stuff it > is fine to require a more modern tool chain.) That's one way to see it. The problem with this statement is a user today is mislead to think you can build Xen with any GCC versions since 4.1. I don't believe we can guarantee that and we are exposing our users to unnecessary risk. In addition to that, I agree with Andrew. This is preventing us to improve our code base and we have to carry hacks for older compilers. > > The one additional concern I've raised in the past is that in the end > it's not just minimal tool chain versions we rely on, but also other > core system tools (see the recent move from "which" to "command -v" > for an example of such a dependency, where luckily it turned out to > not be an issue that the -v had only become a standard thing at some > point). While for the tool chain I can arrange for making newer > versions available, for core system tools I can't. I agree we probably want to clarify the minimum version of the coretools. However, I think we need to separate the two. Otherwise, we will be forever in the statu quo on x86. > Therefore being too > eager there would mean I can't really / easily (smoke) test Xen > anymore on ancient hardware every once in a while. When afaict we do > too little of such testing already anyway, despite not having any > lower bound on hardware that formally we support running Xen on. Can you provide more details of what you mean by "ancient"? > (And > no, upgrading the ancient distros on that ancient hardware is not an > option for me.) May I ask why? Is it because newer distros don't support your HW? Cheers,
On 29.02.2024 11:23, Julien Grall wrote: > On 29/02/2024 07:58, Jan Beulich wrote: >> Therefore being too >> eager there would mean I can't really / easily (smoke) test Xen >> anymore on ancient hardware every once in a while. When afaict we do >> too little of such testing already anyway, despite not having any >> lower bound on hardware that formally we support running Xen on. > > Can you provide more details of what you mean by "ancient"? Formally we support running Xen on any x86 hardware supporting 64-bit mode. I don't think I have any 1st gen systems left, but I think a 2nd gen SVM and a 2nd gen VMX one is what I still have around. >> (And >> no, upgrading the ancient distros on that ancient hardware is not an >> option for me.) > > May I ask why? Is it because newer distros don't support your HW? Because as part of my job I also need to support ancient versions of Xen on ancient distros. Since I need to keep those around, it makes sense to me to then also test modern Xen there (every now and then, as said, and not really extensively). Jan
On 29.02.2024 12:56, Jan Beulich wrote: > On 29.02.2024 11:23, Julien Grall wrote: >> On 29/02/2024 07:58, Jan Beulich wrote: >>> (And >>> no, upgrading the ancient distros on that ancient hardware is not an >>> option for me.) >> >> May I ask why? Is it because newer distros don't support your HW? > > Because as part of my job I also need to support ancient versions of > Xen on ancient distros. Since I need to keep those around, it makes > sense to me to then also test modern Xen there (every now and then, as > said, and not really extensively). Oh, and - because upgrading has proven to take quite a bit of time, if also accounting for all the follow-on work that needs doing when parts of the upgrade didn't quite go as intended. Whether newer distros formally don't support such old hardware is just another possible factor. Jan
On 29/02/2024 10:23 am, Julien Grall wrote: >>>> IOW it is hard for me to see why RISC-V needs stronger restrictions >>>> here >>>> than other architectures. It ought to be possible to determine a >>>> baseline >>>> version. Even if taking the desire to have "pause" available as a >>>> requirement, gas (and presumably gld) 2.36.1 would already suffice. >>> >>> I think we want to bump it on Arm. There are zero reasons to try to >>> keep >>> a lower versions if nobody tests/use it in production. >>> >>> I would suggest to do the same on x86. What's the point of try to >>> support Xen with a 15+ years old compiler? >> >> It could have long been bumped if only a proper scheme to follow for >> this and future bumping would have been put forward by anyone keen on >> such bumping, like - see his reply - e.g. Andrew. You may recall that >> this was discussed more than once on meetings, with no real outcome. >> I'm personally not meaning to stand in the way of such bumping as long >> as it's done in a predictable manner, but I'm not keen on doing so and >> hence I don't view it as my obligation to try to invent a reasonable >> scheme. (My personal view is that basic functionality should be >> possible to have virtually everywhere, whereas for advanced stuff it >> is fine to require a more modern tool chain.) > > That's one way to see it. The problem with this statement is a user > today is mislead to think you can build Xen with any GCC versions > since 4.1. I don't believe we can guarantee that and we are exposing > our users to unnecessary risk. > > In addition to that, I agree with Andrew. This is preventing us to > improve our code base and we have to carry hacks for older compilers. I don't think anyone here is suggesting that we switch to a bleeding-edge-only policy. But 15y of support is extreme in the opposite direction. Xen ought to be buildable in the contemporary distros of the day, and I don't think anyone is going to credibly argue otherwise. But, it's also fine for new things to have newer requirements. Take CET for example. I know we have disagreements on exactly how it's toolchain-conditionalness is implemented, but the basic principle of "If you want shiny new optional feature $X, you need newer toolchain $Y" is entirely fine. A brand new architecture is exactly the same. Saying "this is the minimum, because it's what we test" doesn't preclude someone coming along and saying "can we use $N-1 ? See here it works, and here's a change to CI test it". Anyway, its clear we need to write some policy on this, before making specific adjustments. To get started, is there going to be any objection whatsoever on some principles which begin as follows: * For established architectures, we expect Xen to be buildable on the common contemporary distros. (i.e. minima is not newer than what's available in contemporary distros, without a good reason) * Optional features explicitly may have newer minima, generally chosen by when toolchain support landed and/or was bugfixed suitably to be usable. * Xen won't expect to update minima "just because". But updates across-the-board will be considered periodically where it doesn't conflict with point 1, and where changing the minima allows us to use a new feature to have a positive impact on the codebase. * We always reserve the right to update minima to e.g. avoid crippling code generation bugs, even if it conflicts with point 1. Where workarounds can reasonably be done, they ought to be preferred, but this is ultimately at the discretion of the relevant architecture maintainers. ? ~Andrew
On 29.02.2024 13:05, Andrew Cooper wrote: > On 29/02/2024 10:23 am, Julien Grall wrote: >>>>> IOW it is hard for me to see why RISC-V needs stronger restrictions >>>>> here >>>>> than other architectures. It ought to be possible to determine a >>>>> baseline >>>>> version. Even if taking the desire to have "pause" available as a >>>>> requirement, gas (and presumably gld) 2.36.1 would already suffice. >>>> >>>> I think we want to bump it on Arm. There are zero reasons to try to >>>> keep >>>> a lower versions if nobody tests/use it in production. >>>> >>>> I would suggest to do the same on x86. What's the point of try to >>>> support Xen with a 15+ years old compiler? >>> >>> It could have long been bumped if only a proper scheme to follow for >>> this and future bumping would have been put forward by anyone keen on >>> such bumping, like - see his reply - e.g. Andrew. You may recall that >>> this was discussed more than once on meetings, with no real outcome. >>> I'm personally not meaning to stand in the way of such bumping as long >>> as it's done in a predictable manner, but I'm not keen on doing so and >>> hence I don't view it as my obligation to try to invent a reasonable >>> scheme. (My personal view is that basic functionality should be >>> possible to have virtually everywhere, whereas for advanced stuff it >>> is fine to require a more modern tool chain.) >> >> That's one way to see it. The problem with this statement is a user >> today is mislead to think you can build Xen with any GCC versions >> since 4.1. I don't believe we can guarantee that and we are exposing >> our users to unnecessary risk. >> >> In addition to that, I agree with Andrew. This is preventing us to >> improve our code base and we have to carry hacks for older compilers. > > I don't think anyone here is suggesting that we switch to a > bleeding-edge-only policy. But 15y of support is extreme in the > opposite direction. > > Xen ought to be buildable in the contemporary distros of the day, and I > don't think anyone is going to credibly argue otherwise. > > But, it's also fine for new things to have newer requirements. > > Take CET for example. I know we have disagreements on exactly how it's > toolchain-conditionalness is implemented, but the basic principle of "If > you want shiny new optional feature $X, you need newer toolchain $Y" is > entirely fine. > > A brand new architecture is exactly the same. Saying "this is the > minimum, because it's what we test" doesn't preclude someone coming > along and saying "can we use $N-1 ? See here it works, and here's a > change to CI test it". > > > Anyway, its clear we need to write some policy on this, before making > specific adjustments. To get started, is there going to be any > objection whatsoever on some principles which begin as follows: Largely not, but one aspect needs clarifying up front: > * For established architectures, we expect Xen to be buildable on the > common contemporary distros. (i.e. minima is not newer than what's > available in contemporary distros, without a good reason) What counts as contemporary distro? Still in normal support? LTS? Yet more extreme forms? Plus - whose distros would we consider? Jan > * Optional features explicitly may have newer minima, generally chosen > by when toolchain support landed and/or was bugfixed suitably to be usable. > > * Xen won't expect to update minima "just because". But updates > across-the-board will be considered periodically where it doesn't > conflict with point 1, and where changing the minima allows us to use a > new feature to have a positive impact on the codebase. > > * We always reserve the right to update minima to e.g. avoid crippling > code generation bugs, even if it conflicts with point 1. Where > workarounds can reasonably be done, they ought to be preferred, but this > is ultimately at the discretion of the relevant architecture maintainers. > > ? > > ~Andrew
Hi Andrew, On 29/02/2024 12:05, Andrew Cooper wrote: > On 29/02/2024 10:23 am, Julien Grall wrote: >>>>> IOW it is hard for me to see why RISC-V needs stronger restrictions >>>>> here >>>>> than other architectures. It ought to be possible to determine a >>>>> baseline >>>>> version. Even if taking the desire to have "pause" available as a >>>>> requirement, gas (and presumably gld) 2.36.1 would already suffice. >>>> >>>> I think we want to bump it on Arm. There are zero reasons to try to >>>> keep >>>> a lower versions if nobody tests/use it in production. >>>> >>>> I would suggest to do the same on x86. What's the point of try to >>>> support Xen with a 15+ years old compiler? >>> >>> It could have long been bumped if only a proper scheme to follow for >>> this and future bumping would have been put forward by anyone keen on >>> such bumping, like - see his reply - e.g. Andrew. You may recall that >>> this was discussed more than once on meetings, with no real outcome. >>> I'm personally not meaning to stand in the way of such bumping as long >>> as it's done in a predictable manner, but I'm not keen on doing so and >>> hence I don't view it as my obligation to try to invent a reasonable >>> scheme. (My personal view is that basic functionality should be >>> possible to have virtually everywhere, whereas for advanced stuff it >>> is fine to require a more modern tool chain.) >> >> That's one way to see it. The problem with this statement is a user >> today is mislead to think you can build Xen with any GCC versions >> since 4.1. I don't believe we can guarantee that and we are exposing >> our users to unnecessary risk. >> >> In addition to that, I agree with Andrew. This is preventing us to >> improve our code base and we have to carry hacks for older compilers. > > I don't think anyone here is suggesting that we switch to a > bleeding-edge-only policy. But 15y of support is extreme in the > opposite direction. > > Xen ought to be buildable in the contemporary distros of the day, and I > don't think anyone is going to credibly argue otherwise. > > But, it's also fine for new things to have newer requirements. > > Take CET for example. I know we have disagreements on exactly how it's > toolchain-conditionalness is implemented, but the basic principle of "If > you want shiny new optional feature $X, you need newer toolchain $Y" is > entirely fine. > > A brand new architecture is exactly the same. Saying "this is the > minimum, because it's what we test" doesn't preclude someone coming > along and saying "can we use $N-1 ? See here it works, and here's a > change to CI test it". > > > Anyway, its clear we need to write some policy on this, before making > specific adjustments. To get started, is there going to be any > objection whatsoever on some principles which begin as follows: No objections. > > * For established architectures, we expect Xen to be buildable on the > common contemporary distros. (i.e. minima is not newer than what's > available in contemporary distros, without a good reason) I think we would need to list the distros we are taking into account. Reading the rest of the principles, I am assuming you would be ok if new distros are added if there is a use case. Cheers,
Hi, On 29/02/2024 12:17, Jan Beulich wrote: > On 29.02.2024 13:05, Andrew Cooper wrote: >> On 29/02/2024 10:23 am, Julien Grall wrote: >>>>>> IOW it is hard for me to see why RISC-V needs stronger restrictions >>>>>> here >>>>>> than other architectures. It ought to be possible to determine a >>>>>> baseline >>>>>> version. Even if taking the desire to have "pause" available as a >>>>>> requirement, gas (and presumably gld) 2.36.1 would already suffice. >>>>> >>>>> I think we want to bump it on Arm. There are zero reasons to try to >>>>> keep >>>>> a lower versions if nobody tests/use it in production. >>>>> >>>>> I would suggest to do the same on x86. What's the point of try to >>>>> support Xen with a 15+ years old compiler? >>>> >>>> It could have long been bumped if only a proper scheme to follow for >>>> this and future bumping would have been put forward by anyone keen on >>>> such bumping, like - see his reply - e.g. Andrew. You may recall that >>>> this was discussed more than once on meetings, with no real outcome. >>>> I'm personally not meaning to stand in the way of such bumping as long >>>> as it's done in a predictable manner, but I'm not keen on doing so and >>>> hence I don't view it as my obligation to try to invent a reasonable >>>> scheme. (My personal view is that basic functionality should be >>>> possible to have virtually everywhere, whereas for advanced stuff it >>>> is fine to require a more modern tool chain.) >>> >>> That's one way to see it. The problem with this statement is a user >>> today is mislead to think you can build Xen with any GCC versions >>> since 4.1. I don't believe we can guarantee that and we are exposing >>> our users to unnecessary risk. >>> >>> In addition to that, I agree with Andrew. This is preventing us to >>> improve our code base and we have to carry hacks for older compilers. >> >> I don't think anyone here is suggesting that we switch to a >> bleeding-edge-only policy. But 15y of support is extreme in the >> opposite direction. >> >> Xen ought to be buildable in the contemporary distros of the day, and I >> don't think anyone is going to credibly argue otherwise. >> >> But, it's also fine for new things to have newer requirements. >> >> Take CET for example. I know we have disagreements on exactly how it's >> toolchain-conditionalness is implemented, but the basic principle of "If >> you want shiny new optional feature $X, you need newer toolchain $Y" is >> entirely fine. >> >> A brand new architecture is exactly the same. Saying "this is the >> minimum, because it's what we test" doesn't preclude someone coming >> along and saying "can we use $N-1 ? See here it works, and here's a >> change to CI test it". >> >> >> Anyway, its clear we need to write some policy on this, before making >> specific adjustments. To get started, is there going to be any >> objection whatsoever on some principles which begin as follows: > > Largely not, but one aspect needs clarifying up front: > >> * For established architectures, we expect Xen to be buildable on the >> common contemporary distros. (i.e. minima is not newer than what's >> available in contemporary distros, without a good reason) > > What counts as contemporary distro? Still in normal support? LTS? Yet > more extreme forms? LTS makes sense. More I am not sure. I am under the impression that people using older distros are those that wants a stable system. So they would unlikely try to upgrade the hypervisor. Even for LTS, I would argue that if it has been released 5 years ago, then you probably want to update it at the same time as moving to a newer Xen version. Cheers,
On 29.02.2024 13:32, Julien Grall wrote: > On 29/02/2024 12:17, Jan Beulich wrote: >> On 29.02.2024 13:05, Andrew Cooper wrote: >>> On 29/02/2024 10:23 am, Julien Grall wrote: >>>>>>> IOW it is hard for me to see why RISC-V needs stronger restrictions >>>>>>> here >>>>>>> than other architectures. It ought to be possible to determine a >>>>>>> baseline >>>>>>> version. Even if taking the desire to have "pause" available as a >>>>>>> requirement, gas (and presumably gld) 2.36.1 would already suffice. >>>>>> >>>>>> I think we want to bump it on Arm. There are zero reasons to try to >>>>>> keep >>>>>> a lower versions if nobody tests/use it in production. >>>>>> >>>>>> I would suggest to do the same on x86. What's the point of try to >>>>>> support Xen with a 15+ years old compiler? >>>>> >>>>> It could have long been bumped if only a proper scheme to follow for >>>>> this and future bumping would have been put forward by anyone keen on >>>>> such bumping, like - see his reply - e.g. Andrew. You may recall that >>>>> this was discussed more than once on meetings, with no real outcome. >>>>> I'm personally not meaning to stand in the way of such bumping as long >>>>> as it's done in a predictable manner, but I'm not keen on doing so and >>>>> hence I don't view it as my obligation to try to invent a reasonable >>>>> scheme. (My personal view is that basic functionality should be >>>>> possible to have virtually everywhere, whereas for advanced stuff it >>>>> is fine to require a more modern tool chain.) >>>> >>>> That's one way to see it. The problem with this statement is a user >>>> today is mislead to think you can build Xen with any GCC versions >>>> since 4.1. I don't believe we can guarantee that and we are exposing >>>> our users to unnecessary risk. >>>> >>>> In addition to that, I agree with Andrew. This is preventing us to >>>> improve our code base and we have to carry hacks for older compilers. >>> >>> I don't think anyone here is suggesting that we switch to a >>> bleeding-edge-only policy. But 15y of support is extreme in the >>> opposite direction. >>> >>> Xen ought to be buildable in the contemporary distros of the day, and I >>> don't think anyone is going to credibly argue otherwise. >>> >>> But, it's also fine for new things to have newer requirements. >>> >>> Take CET for example. I know we have disagreements on exactly how it's >>> toolchain-conditionalness is implemented, but the basic principle of "If >>> you want shiny new optional feature $X, you need newer toolchain $Y" is >>> entirely fine. >>> >>> A brand new architecture is exactly the same. Saying "this is the >>> minimum, because it's what we test" doesn't preclude someone coming >>> along and saying "can we use $N-1 ? See here it works, and here's a >>> change to CI test it". >>> >>> >>> Anyway, its clear we need to write some policy on this, before making >>> specific adjustments. To get started, is there going to be any >>> objection whatsoever on some principles which begin as follows: >> >> Largely not, but one aspect needs clarifying up front: >> >>> * For established architectures, we expect Xen to be buildable on the >>> common contemporary distros. (i.e. minima is not newer than what's >>> available in contemporary distros, without a good reason) >> >> What counts as contemporary distro? Still in normal support? LTS? Yet >> more extreme forms? > > LTS makes sense. More I am not sure. I am under the impression that > people using older distros are those that wants a stable system. So they > would unlikely try to upgrade the hypervisor. > > Even for LTS, I would argue that if it has been released 5 years ago, > then you probably want to update it at the same time as moving to a > newer Xen version. For the purposes of distros I agree. For the purposes of individuals I don't: What's wrong with running a newer hypervisor and/or kernel underneath an older distro? Jan
Hi Jan, On 29/02/2024 12:51, Jan Beulich wrote: > On 29.02.2024 13:32, Julien Grall wrote: >> On 29/02/2024 12:17, Jan Beulich wrote: >>> On 29.02.2024 13:05, Andrew Cooper wrote: >>>> On 29/02/2024 10:23 am, Julien Grall wrote: >>>>>>>> IOW it is hard for me to see why RISC-V needs stronger restrictions >>>>>>>> here >>>>>>>> than other architectures. It ought to be possible to determine a >>>>>>>> baseline >>>>>>>> version. Even if taking the desire to have "pause" available as a >>>>>>>> requirement, gas (and presumably gld) 2.36.1 would already suffice. >>>>>>> >>>>>>> I think we want to bump it on Arm. There are zero reasons to try to >>>>>>> keep >>>>>>> a lower versions if nobody tests/use it in production. >>>>>>> >>>>>>> I would suggest to do the same on x86. What's the point of try to >>>>>>> support Xen with a 15+ years old compiler? >>>>>> >>>>>> It could have long been bumped if only a proper scheme to follow for >>>>>> this and future bumping would have been put forward by anyone keen on >>>>>> such bumping, like - see his reply - e.g. Andrew. You may recall that >>>>>> this was discussed more than once on meetings, with no real outcome. >>>>>> I'm personally not meaning to stand in the way of such bumping as long >>>>>> as it's done in a predictable manner, but I'm not keen on doing so and >>>>>> hence I don't view it as my obligation to try to invent a reasonable >>>>>> scheme. (My personal view is that basic functionality should be >>>>>> possible to have virtually everywhere, whereas for advanced stuff it >>>>>> is fine to require a more modern tool chain.) >>>>> >>>>> That's one way to see it. The problem with this statement is a user >>>>> today is mislead to think you can build Xen with any GCC versions >>>>> since 4.1. I don't believe we can guarantee that and we are exposing >>>>> our users to unnecessary risk. >>>>> >>>>> In addition to that, I agree with Andrew. This is preventing us to >>>>> improve our code base and we have to carry hacks for older compilers. >>>> >>>> I don't think anyone here is suggesting that we switch to a >>>> bleeding-edge-only policy. But 15y of support is extreme in the >>>> opposite direction. >>>> >>>> Xen ought to be buildable in the contemporary distros of the day, and I >>>> don't think anyone is going to credibly argue otherwise. >>>> >>>> But, it's also fine for new things to have newer requirements. >>>> >>>> Take CET for example. I know we have disagreements on exactly how it's >>>> toolchain-conditionalness is implemented, but the basic principle of "If >>>> you want shiny new optional feature $X, you need newer toolchain $Y" is >>>> entirely fine. >>>> >>>> A brand new architecture is exactly the same. Saying "this is the >>>> minimum, because it's what we test" doesn't preclude someone coming >>>> along and saying "can we use $N-1 ? See here it works, and here's a >>>> change to CI test it". >>>> >>>> >>>> Anyway, its clear we need to write some policy on this, before making >>>> specific adjustments. To get started, is there going to be any >>>> objection whatsoever on some principles which begin as follows: >>> >>> Largely not, but one aspect needs clarifying up front: >>> >>>> * For established architectures, we expect Xen to be buildable on the >>>> common contemporary distros. (i.e. minima is not newer than what's >>>> available in contemporary distros, without a good reason) >>> >>> What counts as contemporary distro? Still in normal support? LTS? Yet >>> more extreme forms? >> >> LTS makes sense. More I am not sure. I am under the impression that >> people using older distros are those that wants a stable system. So they >> would unlikely try to upgrade the hypervisor. >> >> Even for LTS, I would argue that if it has been released 5 years ago, >> then you probably want to update it at the same time as moving to a >> newer Xen version. > > For the purposes of distros I agree. For the purposes of individuals > I don't: What's wrong with running a newer hypervisor and/or kernel > underneath an older distro? There is nothing wrong. I just don't understand the benefits for us to support that use case. To me there are two sorts of individuals: 1. The ones that are using distro packages. They will unlikely want to switch to a newer hypervisor 2. The ones that are happy to compile and hack their system. Fairly likely they will use a more distros and/or would not be put up by upgrading it. What individuals do you have in mind? Also, for me, the minimum doesn't prevent anyone to try to compile with an older compiler. It is only here to say that as a community we will not investigate or trying to workaround bugs in those compilers. I don't see the problem with that if someone decide to use an older dom0 distros with a newer hypervisor. It would likely not be the only issue they will have. Cheers,
On 29.02.2024 14:44, Julien Grall wrote: > Hi Jan, > > On 29/02/2024 12:51, Jan Beulich wrote: >> On 29.02.2024 13:32, Julien Grall wrote: >>> On 29/02/2024 12:17, Jan Beulich wrote: >>>> On 29.02.2024 13:05, Andrew Cooper wrote: >>>>> On 29/02/2024 10:23 am, Julien Grall wrote: >>>>>>>>> IOW it is hard for me to see why RISC-V needs stronger restrictions >>>>>>>>> here >>>>>>>>> than other architectures. It ought to be possible to determine a >>>>>>>>> baseline >>>>>>>>> version. Even if taking the desire to have "pause" available as a >>>>>>>>> requirement, gas (and presumably gld) 2.36.1 would already suffice. >>>>>>>> >>>>>>>> I think we want to bump it on Arm. There are zero reasons to try to >>>>>>>> keep >>>>>>>> a lower versions if nobody tests/use it in production. >>>>>>>> >>>>>>>> I would suggest to do the same on x86. What's the point of try to >>>>>>>> support Xen with a 15+ years old compiler? >>>>>>> >>>>>>> It could have long been bumped if only a proper scheme to follow for >>>>>>> this and future bumping would have been put forward by anyone keen on >>>>>>> such bumping, like - see his reply - e.g. Andrew. You may recall that >>>>>>> this was discussed more than once on meetings, with no real outcome. >>>>>>> I'm personally not meaning to stand in the way of such bumping as long >>>>>>> as it's done in a predictable manner, but I'm not keen on doing so and >>>>>>> hence I don't view it as my obligation to try to invent a reasonable >>>>>>> scheme. (My personal view is that basic functionality should be >>>>>>> possible to have virtually everywhere, whereas for advanced stuff it >>>>>>> is fine to require a more modern tool chain.) >>>>>> >>>>>> That's one way to see it. The problem with this statement is a user >>>>>> today is mislead to think you can build Xen with any GCC versions >>>>>> since 4.1. I don't believe we can guarantee that and we are exposing >>>>>> our users to unnecessary risk. >>>>>> >>>>>> In addition to that, I agree with Andrew. This is preventing us to >>>>>> improve our code base and we have to carry hacks for older compilers. >>>>> >>>>> I don't think anyone here is suggesting that we switch to a >>>>> bleeding-edge-only policy. But 15y of support is extreme in the >>>>> opposite direction. >>>>> >>>>> Xen ought to be buildable in the contemporary distros of the day, and I >>>>> don't think anyone is going to credibly argue otherwise. >>>>> >>>>> But, it's also fine for new things to have newer requirements. >>>>> >>>>> Take CET for example. I know we have disagreements on exactly how it's >>>>> toolchain-conditionalness is implemented, but the basic principle of "If >>>>> you want shiny new optional feature $X, you need newer toolchain $Y" is >>>>> entirely fine. >>>>> >>>>> A brand new architecture is exactly the same. Saying "this is the >>>>> minimum, because it's what we test" doesn't preclude someone coming >>>>> along and saying "can we use $N-1 ? See here it works, and here's a >>>>> change to CI test it". >>>>> >>>>> >>>>> Anyway, its clear we need to write some policy on this, before making >>>>> specific adjustments. To get started, is there going to be any >>>>> objection whatsoever on some principles which begin as follows: >>>> >>>> Largely not, but one aspect needs clarifying up front: >>>> >>>>> * For established architectures, we expect Xen to be buildable on the >>>>> common contemporary distros. (i.e. minima is not newer than what's >>>>> available in contemporary distros, without a good reason) >>>> >>>> What counts as contemporary distro? Still in normal support? LTS? Yet >>>> more extreme forms? >>> >>> LTS makes sense. More I am not sure. I am under the impression that >>> people using older distros are those that wants a stable system. So they >>> would unlikely try to upgrade the hypervisor. >>> >>> Even for LTS, I would argue that if it has been released 5 years ago, >>> then you probably want to update it at the same time as moving to a >>> newer Xen version. >> >> For the purposes of distros I agree. For the purposes of individuals >> I don't: What's wrong with running a newer hypervisor and/or kernel >> underneath an older distro? > > There is nothing wrong. I just don't understand the benefits for us to > support that use case. To me there are two sorts of individuals: > 1. The ones that are using distro packages. They will unlikely want to > switch to a newer hypervisor > 2. The ones that are happy to compile and hack their system. Fairly > likely they will use a more distros and/or would not be put up by > upgrading it. > > What individuals do you have in mind? People like me. > Also, for me, the minimum doesn't prevent anyone to try to compile with > an older compiler. It is only here to say that as a community we will > not investigate or trying to workaround bugs in those compilers. Besides this also allowing to use functionality you won't have an easy way of replacing, what you say also doesn't make clear whether - for cases where the issue can be (reasonably easily) worked around - patches would be accepted, or rejected on the basis of only helping a below-the- line compiler. Jan
On 29/02/2024 14:07, Jan Beulich wrote: > On 29.02.2024 14:44, Julien Grall wrote: >> Hi Jan, >> >> On 29/02/2024 12:51, Jan Beulich wrote: >>> On 29.02.2024 13:32, Julien Grall wrote: >>>> On 29/02/2024 12:17, Jan Beulich wrote: >>>>> On 29.02.2024 13:05, Andrew Cooper wrote: >>>>>> On 29/02/2024 10:23 am, Julien Grall wrote: >>>>>>>>>> IOW it is hard for me to see why RISC-V needs stronger restrictions >>>>>>>>>> here >>>>>>>>>> than other architectures. It ought to be possible to determine a >>>>>>>>>> baseline >>>>>>>>>> version. Even if taking the desire to have "pause" available as a >>>>>>>>>> requirement, gas (and presumably gld) 2.36.1 would already suffice. >>>>>>>>> >>>>>>>>> I think we want to bump it on Arm. There are zero reasons to try to >>>>>>>>> keep >>>>>>>>> a lower versions if nobody tests/use it in production. >>>>>>>>> >>>>>>>>> I would suggest to do the same on x86. What's the point of try to >>>>>>>>> support Xen with a 15+ years old compiler? >>>>>>>> >>>>>>>> It could have long been bumped if only a proper scheme to follow for >>>>>>>> this and future bumping would have been put forward by anyone keen on >>>>>>>> such bumping, like - see his reply - e.g. Andrew. You may recall that >>>>>>>> this was discussed more than once on meetings, with no real outcome. >>>>>>>> I'm personally not meaning to stand in the way of such bumping as long >>>>>>>> as it's done in a predictable manner, but I'm not keen on doing so and >>>>>>>> hence I don't view it as my obligation to try to invent a reasonable >>>>>>>> scheme. (My personal view is that basic functionality should be >>>>>>>> possible to have virtually everywhere, whereas for advanced stuff it >>>>>>>> is fine to require a more modern tool chain.) >>>>>>> >>>>>>> That's one way to see it. The problem with this statement is a user >>>>>>> today is mislead to think you can build Xen with any GCC versions >>>>>>> since 4.1. I don't believe we can guarantee that and we are exposing >>>>>>> our users to unnecessary risk. >>>>>>> >>>>>>> In addition to that, I agree with Andrew. This is preventing us to >>>>>>> improve our code base and we have to carry hacks for older compilers. >>>>>> >>>>>> I don't think anyone here is suggesting that we switch to a >>>>>> bleeding-edge-only policy. But 15y of support is extreme in the >>>>>> opposite direction. >>>>>> >>>>>> Xen ought to be buildable in the contemporary distros of the day, and I >>>>>> don't think anyone is going to credibly argue otherwise. >>>>>> >>>>>> But, it's also fine for new things to have newer requirements. >>>>>> >>>>>> Take CET for example. I know we have disagreements on exactly how it's >>>>>> toolchain-conditionalness is implemented, but the basic principle of "If >>>>>> you want shiny new optional feature $X, you need newer toolchain $Y" is >>>>>> entirely fine. >>>>>> >>>>>> A brand new architecture is exactly the same. Saying "this is the >>>>>> minimum, because it's what we test" doesn't preclude someone coming >>>>>> along and saying "can we use $N-1 ? See here it works, and here's a >>>>>> change to CI test it". >>>>>> >>>>>> >>>>>> Anyway, its clear we need to write some policy on this, before making >>>>>> specific adjustments. To get started, is there going to be any >>>>>> objection whatsoever on some principles which begin as follows: >>>>> >>>>> Largely not, but one aspect needs clarifying up front: >>>>> >>>>>> * For established architectures, we expect Xen to be buildable on the >>>>>> common contemporary distros. (i.e. minima is not newer than what's >>>>>> available in contemporary distros, without a good reason) >>>>> >>>>> What counts as contemporary distro? Still in normal support? LTS? Yet >>>>> more extreme forms? >>>> >>>> LTS makes sense. More I am not sure. I am under the impression that >>>> people using older distros are those that wants a stable system. So they >>>> would unlikely try to upgrade the hypervisor. >>>> >>>> Even for LTS, I would argue that if it has been released 5 years ago, >>>> then you probably want to update it at the same time as moving to a >>>> newer Xen version. >>> >>> For the purposes of distros I agree. For the purposes of individuals >>> I don't: What's wrong with running a newer hypervisor and/or kernel >>> underneath an older distro? >> >> There is nothing wrong. I just don't understand the benefits for us to >> support that use case. To me there are two sorts of individuals: >> 1. The ones that are using distro packages. They will unlikely want to >> switch to a newer hypervisor >> 2. The ones that are happy to compile and hack their system. Fairly >> likely they will use a more distros and/or would not be put up by >> upgrading it. >> >> What individuals do you have in mind? > > People like me. Which means? From what I read you mostly use an older distros for smoke testing/convenience. >> Also, for me, the minimum doesn't prevent anyone to try to compile with >> an older compiler. It is only here to say that as a community we will >> not investigate or trying to workaround bugs in those compilers. > > Besides this also allowing to use functionality you won't have an easy > way of replacing, what you say also doesn't make clear whether - for > cases where the issue can be (reasonably easily) worked around - patches > would be accepted, or rejected on the basis of only helping a below-the- > line compiler. I would not accept them. Cheers,
On Thu, 2024-02-29 at 08:58 +0100, Jan Beulich wrote: > On 28.02.2024 23:58, Julien Grall wrote: > > On 27/02/2024 07:55, Jan Beulich wrote: > > > On 26.02.2024 18:39, Oleksii Kurochko wrote: > > > > This patch doesn't represent a strict lower bound for GCC and > > > > GNU Binutils; rather, these versions are specifically employed > > > > by > > > > the Xen RISC-V container and are anticipated to undergo > > > > continuous > > > > testing. > > > > > > Up and until that container would be updated to a newer gcc. I'm > > > afraid I view this as too weak a criteria, > > > > I disagree. We have to decide a limit at some point. It is sensible > > to > > say that we are only supporting what we can tests. AFAIK, this is > > what > > QEMU has been doing. > > I view qemu as a particularly bad example. They raise their baselines > far too aggressively for my taste. > > > > IOW it is hard for me to see why RISC-V needs stronger > > > restrictions here > > > than other architectures. It ought to be possible to determine a > > > baseline > > > version. Even if taking the desire to have "pause" available as a > > > requirement, gas (and presumably gld) 2.36.1 would already > > > suffice. > > > > I think we want to bump it on Arm. There are zero reasons to try to > > keep > > a lower versions if nobody tests/use it in production. > > > > I would suggest to do the same on x86. What's the point of try to > > support Xen with a 15+ years old compiler? > > It could have long been bumped if only a proper scheme to follow for > this and future bumping would have been put forward by anyone keen on > such bumping, like - see his reply - e.g. Andrew. You may recall that > this was discussed more than once on meetings, with no real outcome. > I'm personally not meaning to stand in the way of such bumping as > long > as it's done in a predictable manner, but I'm not keen on doing so > and > hence I don't view it as my obligation to try to invent a reasonable > scheme. (My personal view is that basic functionality should be > possible to have virtually everywhere, whereas for advanced stuff it > is fine to require a more modern tool chain.) > > The one additional concern I've raised in the past is that in the end > it's not just minimal tool chain versions we rely on, but also other > core system tools (see the recent move from "which" to "command -v" > for an example of such a dependency, where luckily it turned out to > not be an issue that the -v had only become a standard thing at some > point). While for the tool chain I can arrange for making newer > versions available, for core system tools I can't. Can't we identify the top X most popular Linux distributions ( LTS versions ) and align Xen's minimal toolchain version with the selected distributions' minimum toolchain versions? > Therefore being too > eager there would mean I can't really / easily (smoke) test Xen > anymore on ancient hardware every once in a while. When afaict we do > too little of such testing already anyway, despite not having any > lower bound on hardware that formally we support running Xen on. (And > no, upgrading the ancient distros on that ancient hardware is not an > option for me.) It seems there is no room for upgrading the toolchain version. This leads to the question of determining the threshold between maintaining the version as minimal as possible and deciding to upgrade it. I understand your situation where you have an ancient hardware that necessitates the use of older Linux distributions. However, is this a common use case? ~ Oleksii
On Wed, 2024-02-28 at 23:11 +0000, Andrew Cooper wrote: > Furthermore, Linux has regularly been bumping minimum toolchain > versions > due to code generation issues, and we'd be foolish not pay attention. Do they document that? It looks like their doc is pretty old, because in Documentation/Changes it is mentioned: GNU C 5.1 gcc --version And RISC-V support in GCC wad added after 7.0 or so... But there is also the following words: This document is originally based on my "Changes" file for 2.0.x kernels and therefore owes credit to the same people as that file (Jared Mauch, Axel Boldt, Alessandro Sigala, and countless other users all over the 'net). Probably the doc wasn't updated for a long time, but at the same time there is a line with Rust: Rust (optional) 1.62.0 rustc --version ~ Oleksii
On Thu, 29 Feb 2024, Julien Grall wrote: > On 29/02/2024 14:07, Jan Beulich wrote: > > On 29.02.2024 14:44, Julien Grall wrote: > > > Hi Jan, > > > > > > On 29/02/2024 12:51, Jan Beulich wrote: > > > > On 29.02.2024 13:32, Julien Grall wrote: > > > > > On 29/02/2024 12:17, Jan Beulich wrote: > > > > > > On 29.02.2024 13:05, Andrew Cooper wrote: > > > > > > > On 29/02/2024 10:23 am, Julien Grall wrote: > > > > > > > > > > > IOW it is hard for me to see why RISC-V needs stronger > > > > > > > > > > > restrictions > > > > > > > > > > > here > > > > > > > > > > > than other architectures. It ought to be possible to > > > > > > > > > > > determine a > > > > > > > > > > > baseline > > > > > > > > > > > version. Even if taking the desire to have "pause" > > > > > > > > > > > available as a > > > > > > > > > > > requirement, gas (and presumably gld) 2.36.1 would already > > > > > > > > > > > suffice. > > > > > > > > > > > > > > > > > > > > I think we want to bump it on Arm. There are zero reasons to > > > > > > > > > > try to > > > > > > > > > > keep > > > > > > > > > > a lower versions if nobody tests/use it in production. > > > > > > > > > > > > > > > > > > > > I would suggest to do the same on x86. What's the point of > > > > > > > > > > try to > > > > > > > > > > support Xen with a 15+ years old compiler? > > > > > > > > > > > > > > > > > > It could have long been bumped if only a proper scheme to > > > > > > > > > follow for > > > > > > > > > this and future bumping would have been put forward by anyone > > > > > > > > > keen on > > > > > > > > > such bumping, like - see his reply - e.g. Andrew. You may > > > > > > > > > recall that > > > > > > > > > this was discussed more than once on meetings, with no real > > > > > > > > > outcome. > > > > > > > > > I'm personally not meaning to stand in the way of such bumping > > > > > > > > > as long > > > > > > > > > as it's done in a predictable manner, but I'm not keen on > > > > > > > > > doing so and > > > > > > > > > hence I don't view it as my obligation to try to invent a > > > > > > > > > reasonable > > > > > > > > > scheme. (My personal view is that basic functionality should > > > > > > > > > be > > > > > > > > > possible to have virtually everywhere, whereas for advanced > > > > > > > > > stuff it > > > > > > > > > is fine to require a more modern tool chain.) > > > > > > > > > > > > > > > > That's one way to see it. The problem with this statement is a > > > > > > > > user > > > > > > > > today is mislead to think you can build Xen with any GCC > > > > > > > > versions > > > > > > > > since 4.1. I don't believe we can guarantee that and we are > > > > > > > > exposing > > > > > > > > our users to unnecessary risk. > > > > > > > > > > > > > > > > In addition to that, I agree with Andrew. This is preventing us > > > > > > > > to > > > > > > > > improve our code base and we have to carry hacks for older > > > > > > > > compilers. > > > > > > > > > > > > > > I don't think anyone here is suggesting that we switch to a > > > > > > > bleeding-edge-only policy. But 15y of support is extreme in the > > > > > > > opposite direction. > > > > > > > > > > > > > > Xen ought to be buildable in the contemporary distros of the day, > > > > > > > and I > > > > > > > don't think anyone is going to credibly argue otherwise. > > > > > > > > > > > > > > But, it's also fine for new things to have newer requirements. > > > > > > > > > > > > > > Take CET for example. I know we have disagreements on exactly how > > > > > > > it's > > > > > > > toolchain-conditionalness is implemented, but the basic principle > > > > > > > of "If > > > > > > > you want shiny new optional feature $X, you need newer toolchain > > > > > > > $Y" is > > > > > > > entirely fine. > > > > > > > > > > > > > > A brand new architecture is exactly the same. Saying "this is the > > > > > > > minimum, because it's what we test" doesn't preclude someone > > > > > > > coming > > > > > > > along and saying "can we use $N-1 ? See here it works, and here's > > > > > > > a > > > > > > > change to CI test it". > > > > > > > > > > > > > > > > > > > > > Anyway, its clear we need to write some policy on this, before > > > > > > > making > > > > > > > specific adjustments. To get started, is there going to be any > > > > > > > objection whatsoever on some principles which begin as follows: > > > > > > > > > > > > Largely not, but one aspect needs clarifying up front: > > > > > > > > > > > > > * For established architectures, we expect Xen to be buildable on > > > > > > > the > > > > > > > common contemporary distros. (i.e. minima is not newer than > > > > > > > what's > > > > > > > available in contemporary distros, without a good reason) > > > > > > > > > > > > What counts as contemporary distro? Still in normal support? LTS? > > > > > > Yet > > > > > > more extreme forms? > > > > > > > > > > LTS makes sense. More I am not sure. I am under the impression that > > > > > people using older distros are those that wants a stable system. So > > > > > they > > > > > would unlikely try to upgrade the hypervisor. > > > > > > > > > > Even for LTS, I would argue that if it has been released 5 years ago, > > > > > then you probably want to update it at the same time as moving to a > > > > > newer Xen version. > > > > > > > > For the purposes of distros I agree. For the purposes of individuals > > > > I don't: What's wrong with running a newer hypervisor and/or kernel > > > > underneath an older distro? > > > > > > There is nothing wrong. I just don't understand the benefits for us to > > > support that use case. To me there are two sorts of individuals: > > > 1. The ones that are using distro packages. They will unlikely want to > > > switch to a newer hypervisor > > > 2. The ones that are happy to compile and hack their system. Fairly > > > likely they will use a more distros and/or would not be put up by > > > upgrading it. > > > > > > What individuals do you have in mind? > > > > People like me. > > Which means? From what I read you mostly use an older distros for smoke > testing/convenience. This is a cost/benefit decision. Supporting new Xen on ancient distros has a cost for maintainers and contributors. Is it worth paying this cost for the benefits it provides? It is natural that different people are going to have different opinions on this, because their use-case and situation are different. We need to define exactly what "ancient" distro means, but from what I see my answer is "no, it is not worth it". For example, for ARM I would raise the minimum GCC version to something around GCC5.
diff --git a/README b/README index c8a108449e..7fd4173743 100644 --- a/README +++ b/README @@ -48,6 +48,15 @@ provided by your OS distributor: - For ARM 64-bit: - GCC 5.1 or later - GNU Binutils 2.24 or later + - For RISC-V 64-bit: + - GCC 12.2 or later + - GNU Binutils 2.39 or later + This doesn't represent a strict lower bound for GCC and GNU Binutils; + rather, these versions are specifically employed by the Xen RISC-V + container and are anticipated to undergo continuous testing. + While it is feasible to utilize Clang, it's important to note that, + currently, there is no Xen RISC-V CI job in place to verify the + seamless functioning of the build with Clang. * POSIX compatible awk * Development install of zlib (e.g., zlib-dev) * Development install of Python 2.7 or later (e.g., python-dev)
This patch doesn't represent a strict lower bound for GCC and GNU Binutils; rather, these versions are specifically employed by the Xen RISC-V container and are anticipated to undergo continuous testing. While it is feasible to utilize Clang, it's important to note that, currently, there is no Xen RISC-V CI job in place to verify the seamless functioning of the build with Clang. Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> --- Changes in V5: - update the commit message and README file with additional explanation about GCC and GNU Binutils version. Additionally, it was added information about Clang. --- Changes in V4: - Update version of GCC (12.2) and GNU Binutils (2.39) to the version which are in Xen's contrainter for RISC-V --- Changes in V3: - new patch --- README | 9 +++++++++ 1 file changed, 9 insertions(+)