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

[Julien Grall <julien@xxxxxxx>]

On 29/02/2024 07:58, Jan Beulich wrote:
> On 28.02.2024 23:58, Julien Grall wrote:
> > On 27/02/2024 07:55, Jan Beulich wrote:
> > > On 26.02.2024 18:39, Oleksii Kurochko wrote:
> > > > This patch doesn't represent a strict lower bound for GCC and
> > > > GNU Binutils; rather, these versions are specifically employed by
> > > > the Xen RISC-V container and are anticipated to undergo continuous
> > > > testing.
> > > Up and until that container would be updated to a newer gcc. I'm
> > > afraid I view this as too weak a criteria,
> > I disagree. We have to decide a limit at some point. It is sensible to
> > say that we are only supporting what we can tests. AFAIK, this is what
> > QEMU has been doing.
> I view qemu as a particularly bad example. They raise their baselines
> far too aggressively for my taste.
AFAICT, the decision was based on the supported distros at the time. 
Which makes sense to me (even though I got recently caught because of 
this check). They also seem to be open to relax the check if there are 
any use cases.
Why would we want to support build Xen on non-supported distros?

> > > 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.
> The one additional concern I've raised in the past is that in the end
> it's not just minimal tool chain versions we rely on, but also other
> core system tools (see the recent move from "which" to "command -v"
> for an example of such a dependency, where luckily it turned out to
> not be an issue that the -v had only become a standard thing at some
> point). While for the tool chain I can arrange for making newer
> versions available, for core system tools I can't.
I agree we probably want to clarify the minimum version of the 
coretools. However, I think we need to separate the two. Otherwise, we 
will be forever in the statu quo on x86.
> Therefore being too
> eager there would mean I can't really / easily (smoke) test Xen
> anymore on ancient hardware every once in a while. When afaict we do
> too little of such testing already anyway, despite not having any
> lower bound on hardware that formally we support running Xen on.
Can you provide more details of what you mean by "ancient"?

> (And
> no, upgrading the ancient distros on that ancient hardware is not an
> option for me.)
May I ask why? Is it because newer distros don't support your HW?

Cheers,

--
Julien Grall