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
