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

[Jan Beulich <jbeulich@suse.com>]

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