Re: [PATCH-for-10.1 00/13] arm: Spring header cleanups

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

On 4/3/25 12:31, Philippe Mathieu-Daudé wrote:
> On 3/4/25 20:22, Pierrick Bouvier wrote:
>> On 4/2/25 15:23, Philippe Mathieu-Daudé wrote:
>>> This series is more useful for heterogeneous emulation preparation
>>> than single binary, because it allows non-ARM hw/ code to configure
>>> ARM cores, so not using target-specific APIs. I figured some
>>> patches could be useful to Pierrick "build hw/arm once" series (in
>>> particular arm_cpu_has_feature).
>>>
>>
>> I'm ok with the cleanup part, as I sent a reviewed-by.
>>
>> However, I'm not sure in which context non-ARM hw/ code will really need
>> to do it. It would be better if we stick to mandatory changes for now,
>> instead of anticipating future needs, which might be real or not.
>> We can implement those changes only as part of a series that really
>> needs it.
> 
> I understand your view. I had to rebase these now old patches, and
> figured it will cost me less if I get them merged, rather than
> keeping rebasing them for 4 or 5 releases.
> 

Sure, that's the best approach. For the reviewer, it's not obvious when 
you implemented this though, so the only question we can ask is "Why is 
that needed?".

> Single binary effort is just a milestone toward heterogeneous emulation.

Yes. That said, it does not change the fact that anticipating needs 
(i.e. not explicitely required to compile/execute right now) can detour 
us from the goal, whether it's the single binary, heterogeneous 
emulation, or any feature we want to add to QEMU.

In the context of this series, it's still not obvious for me why a piece 
of hardware not related to Arm would poke internal registers to detect 
if a feature is implemented or not. Thus, it's not obvious why we need 
to expose that now. If we don't have an answer to that, I suggest to 
postpone this part of the series until we get a real use case.

For the cleanup part, as I mentioned before, I'm totally ok with it.