On Thu, 5 Mar 2026, Peter Xu wrote:
On Thu, Mar 05, 2026 at 11:15:59AM +0000, Mark Cave-Ayland wrote:
On 03/03/2026 09:51, Peter Maydell wrote:
On Sun, 1 Mar 2026 at 21:03, BALATON Zoltan <[email protected]> wrote:
Use memory_region_init_rom() instead which is what other devices do.
This is breaks migration but these devices are only used on sparc Sun
machines which have no migration compatibility guarantee.
Signed-off-by: BALATON Zoltan <[email protected]>
---
hw/display/cg3.c | 5 ++---
hw/display/tcx.c | 5 ++---
2 files changed, 4 insertions(+), 6 deletions(-)
Reviewed-by: Peter Maydell <[email protected]>
I think the compat break on these machines is worth it
to make progress on the cleanup of these functions.
Hi Peter,
Hi, Mark,
[some pure thoughts before PeterM chimes in..]
From what I can see there is still on-going discussion on this series,
however if the general consensus is that the removal of the last of these
legacy functions is now imminent then I won't object if you want to merge
this.
In this case it's not easy to reach a consensus collecting "yes"s but
"no"s, that who still prefer this ABI to be kept.
Personally, I would respect your opinion, and I queued them because from
what I read the impact seems under control, please correct me otherwise.
There's indeed the dilemma that since sparc machines are not versioned,
then it's easier to be treated as a system that may not demand the highest
level of ABI guarantees.
It's also harder to consider ABI compatibility for un-versioned machs
comparing to versioned.
It's because for other versioned machines, we have the ~6 years lifespan
nowadays for them so we can drop old things over specific period of time.
While when a machine is not versioned, it's almost impossible to mark the
time of deprecation.
We either need to choose to maintain ABI for those machines forever, or we
allow ABI break to some degree. When a machine is not versioned, it's
harder to justify we maintain these machines' ABI even longer than
versioned machines (which we deemed to be "relatively serious" users).
So if we want to stick with that machine versioning plan, maybe we should
start version machines that we may care on ABIs. IIUC it doesn't need to
introduce one machine type every release, however when versioned we will be
able to follow the same ~6 years obsoletion phase at least.
Considering that this was intruduced in 2017 around commit 1cfe48c1ce2 and
most other users were converted back then it's well over 6 years now even
without versioning. Thanks to Mark for accepting changing it now.
I've dropped the debated part about errp from the v7 of the series so all
remaining clean ups should be simple enough to review and merge before the
freeze. Could you please have a look at those too?
Regards,
BALATON Zoltan
