[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 29 Feb 2024 15:07:25 +0100
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: George Dunlap <george.dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Thu, 29 Feb 2024 14:07:33 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 29.02.2024 14:44, Julien Grall wrote:
> Hi Jan,
> 
> On 29/02/2024 12:51, Jan Beulich wrote:
>> 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?
> 
> There is nothing wrong. I just don't understand the benefits for us to 
> support that use case. To me there are two sorts of individuals:
>   1. The ones that are using distro packages. They will unlikely want to 
> switch to a newer hypervisor
>   2. The ones that are happy to compile and hack their system. Fairly 
> likely they will use a more distros and/or would not be put up by 
> upgrading it.
> 
> What individuals do you have in mind?

People like me.

> Also, for me, the minimum doesn't prevent anyone to try to compile with 
> an older compiler. It is only here to say that as a community we will 
> not investigate or trying to workaround bugs in those compilers.

Besides this also allowing to use functionality you won't have an easy
way of replacing, what you say also doesn't make clear whether - for
cases where the issue can be (reasonably easily) worked around - patches
would be accepted, or rejected on the basis of only helping a below-the-
line compiler.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.