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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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