On 27/12/25 16:51, Philippe Mathieu-Daudé wrote:
On 27/12/25 09:56, Paolo Bonzini wrote:
Il mer 24 dic 2025, 16:24 Philippe Mathieu-Daudé <[email protected]
<mailto:[email protected]>> ha scritto:
Guard the native endian APIs we want to remove by surrounding
them with TARGET_NOT_USING_LEGACY_NATIVE_ENDIAN_API #ifdef'ry.
Once a target gets cleaned we'll set the definition in the
target config, then the target won't be able to use the legacy
API anymore.
Host endianness APIs are fine and are used when talking to the kernel.
These functions that take a void* should not be included in
TARGET_NOT_USING_LEGACY_NATIVE_ENDIAN_API.
(And also they are the same for all targets so they don't get in the
way of the single binary effort).
Indeed they don't get in the way: I'm trying to have clearer APIs where
everything is explicit. Anyway I can live keeping this for now.
I guess remembering my reasoning was:
1/ we can not have "guest native" endianness in single binary
2/ host endianness is only useful with "guest native" one,
otherwise if you know the guest endianness, you can just
use an explicit cpu_to_$endian method.
3/ thus once guest native endianness is gone there is no
usefulness of "host endianness", better to remove instead
of wondering "in which endianness is my host" and let the
compiler do better than us all possible optimisations.
I felt confident it was coherent because, except the ATI single
one-line case [*] which I believe is not the best implementation,
the rest of my series proved this API is easily removable, the
resulting code ending easier to understand IMHO.
I surely missed something and would like to be pointed at it,
so maybe I can revisit my approach.
[*]
https://lore.kernel.org/qemu-devel/[email protected]/
If the only change needed in the series is to drop this patch, don't
bother with reposting.
OK, thanks.
