Re: [PATCH v5 23/23] xen/README: add compiler and binutils versions for RISC-V64

[Julien Grall <julien@xxxxxxx>]

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,

--
Julien Grall