|
| From: | BALATON Zoltan |
| Subject: | Re: [PATCH v4 16/19] mac_newworld: Add machine types for different mac99 configs |
| Date: | Sat, 29 Oct 2022 14:35:54 +0200 (CEST) |
On Sat, 29 Oct 2022, Mark Cave-Ayland wrote:
On 28/10/2022 13:18, BALATON Zoltan wrote:On Fri, 28 Oct 2022, Mark Cave-Ayland wrote:On 25/10/2022 17:44, BALATON Zoltan wrote:The mac99 machine emulates different machines depending on machine properties or even if it is run as qemu-system-ppc64 or qemu-system-ppc. This is very confusing for users and many hours were lost trying to explain it or finding out why commands users came up with are not working as expected. (E.g. Windows users might think qemu-system-ppc64 is just the 64 bit version of qemu-system-ppc and then fail to boot a 32 bit OS with -M mac99 trying to follow an example that had qemu-system-ppc.) To avoid such confusion, add explicit machine types for the different configs which will work the same with both qemu-system-ppc and qemu-system-ppc64 and also make the command line clearer for new users.What was the outcome of the discussion re: having separate machines for 32-bit and 64-bit PPC targets? My understanding is the issue here was deciding what to do, rather than actually making the code changes.Who do you think will or should decide about this? There are about 3 people who care about Mac emulation on this list: you, Howard and me. You already have my and Howard's vote to introduce these machines types. Who else should vote or decide on this? Please apply this patch now and if it causes problem it can still be dropped duting the freeze but if you don't apply it now it can't get into before next spring.This is not restricted to qemu-system-ppc though: there was a discussion (which was still ongoing) as to how all of QEMU should handle 32-bit and 64-bit machines i.e. should qemu-system-ppc64 only contain 64-bit machines and qemu-system-ppc only contain 32-bit machines? If we wish to make a change here, we should wait for the outcome of this to ensure consistency here.
That's unrelated to mac99 then so we can sort that out independently now as this will be needed anyway to remove the confusing behaviour of mac99 emulating different machines depending if it's part of qemu-system-ppc or qemu-system-ppc64. Whatever the decision with 32 vs 64 bit will be this will have to go so better deprecate it now so we can more easily adapt whatever that decision will be (if it will have a decision in the near fututre at all). I don't think that's a good reason to ditch this patch as I don't see this is getting to a decision soon which would need doing else than deprecating mac99.
Also what was your motivation for choosing the machine names? I see you've used powerbook for via=pmu-adb, but I think quite a few people use pmu-adb for older OS X server hardware. At the very least some pointers to reference device trees and some rationale behind the decision is needed for review.See my reply to Howard's message with some more info and links. My immediate motivation was that we've lost about two days when somobody contacted me about VGA pass through sending logs about all kinds of failures he got. After many logs I've noticed that he was using qemu-system-ppc64 -M mac99,via=pmu thinking that on 64bit host that's the executable he should use. Unfortunately the commands were not shared just the logs so this took a while to notice. Also if you look at the forum Howard runs you can see this problem is coming up frequently and I think the've also lost countless hours due to this. It's about time to put an end on it and stop wasting othet's time. As for The machines, the powermac ones are straight forward as those are closest to what we emulate for G4 and G5 Mac. I've chosen the powerbook becuase that's the only machine I know that had PMU and ADB but If someone knows a better machine we can change this (even as bug fix during the freeze). Here's some info on this powerbook: https://ppc.0penbsd.narkive.com/s49Kcx1u/x-on-powerbook-g4In all my time working on QEMU this has happened to me once: yes, I agree it can be annoying but given how rare it happens I don't see a need to make a rushed decision now.
Maybe because you don't work with users like Howard or don't work with ati-vga like me. But we got this problem many times, I've got bitten by forgetting the vga-ndrv? option several times and had to remember this is breaking stuff so that this works for you is no reason to believe it's not causing problems for anybody. A better approach may be if a proposed solution is not breaking anything for you then accept it rather than having the basic view of resisting any change from anywhere. As a private developer you can so that but as a maintainer you should not lock out others from contributing and be more accepting or other solutions.
In terms of choosing the machines for QEMU we will need a full copy of the DT from real hardware for comparison with OpenBIOS, and ideally a Linux dmesg.
I don't use that pmu-adb config and I think maybe we don't even need it once USB emulation is fixed on powermac3_1 as those OSes should support powermac3_1 or g3beige so I'm OK with dropping this powerbook machine for now and only merging the powermac3_1 and powermac7_3 machines which I care more about. Can you change the patches accordingly before merge or you want me to submit another version with this chnage? You could also take the first 14 patches if you're OK with them now so I have to resend less.
Regards, BALATON Zoltan
| [Prev in Thread] | Current Thread | [Next in Thread] |