On 3/24/25 10:29, Alex Bennée wrote:
Philippe Mathieu-Daudé <[email protected]> writes:
On 24/3/25 11:21, Alex Bennée wrote:
We've not yet deprecated but we should steer users away from these
helpers if they want to be in a single/heterogeneous binary.
Why not deprecate?
I guess philosophically do we expect to eventually convert all frontends
to the new API or only those that want to be in the single binary?
Should I just be more explicit:
*
* These are all used by the various frontends and have to be host
- * aware to ensure things are store in target order.
+ * aware to ensure things are store in target order. Consider using
+ * the endian neutral registers.h if you want the architecture to be
+ * included in an eventual single QEMU binary.
*
* Copyright (c) 2022 Linaro Ltd
*
These are all used by the various frontends and have to be host aware
to ensure things are store in target order.
If the fix is an easy "sed like" with static typing guarantee (so no bug
can be introduced), we can probably just do it on all existing targets,
and remove this.
If it's hard or error prone, then I would say it's ok to use a "one
target at a time" approach.
New front-ends should not be using these APIs at all. They should be
using the endian neutral registers.h as should any architecture that
intends to be included in an eventual single QEMU binary.
