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
