On Sun, 22 Jan 2023, Mark Cave-Ayland wrote:
On 12/01/2023 23:51, BALATON Zoltan wrote:
On Thu, 12 Jan 2023, Howard Spoelstra wrote:
On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan <bala...@eik.bme.hu> wrote:
On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
On 04/01/2023 21:59, BALATON Zoltan wrote:
Setting emulated machine type with a property called "via" is
confusing users so deprecate the "via" option in favour of newly added
explicit machine types. The default via=cuda option is not a valid
config (no real Mac has this combination of hardware) so no machine
type could be defined for that therefore it is kept for backwards
compatibility with older QEMU versions for now but other options
resembling real machines are deprecated.
Signed-off-by: BALATON Zoltan <bala...@eik.bme.hu>
I believe that people do use -M mac99,via=cuda to run some rare versions
of
MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we
would
want to keep this option somewhere.
The idea is that after previous patches we now have machine types for all
other via option values (that also match real Mac machines) other than
via=cude but that is the default for mac99 so after the reprecation
period
when the via option is removed mac99 (which is the same as
mac99,via=cuda)
can remain for this use case (and for backward compatibility) until the
other machines are fixed to not need this any more. So all via options
are
still available but as different machine types.
My 2 cents about naming:
It seems less important how the machines are named when their name is not
covering their definition. F.i. the powermac3,1 never had adb, could not
be
equipped with a G3 cpu, did not run at 900Mhz. The closest possible
qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac
OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is
already needed.
What does that mean? Should we aim to emulate real Macs or are we happy
with the Franken-Mac we have now? The names also show what we intend to
emulate even though the emulation may not be complete or have bugs (this is
also true for other machines in QEMU where a lot of them are not fully
emulated, only well enough to boot guest OSes).
Looks like everybody has forgotten the previous discussion and not read the
docs and deprecation patches where this is explained so I summarise the
proposed change here again:
- qemu-system-ppc -M mac99 is unchanged and works like before it just warns
for the via option and when using it in qemu-system-ppc64 suggesting using
new machines instead so these could evetually be removed next year.
mac99,via=cuda is just mac99 so you can continue to use that, mac99 is not
deprecated and don't want to remove it.
- qemu-system-ppc64 -M mac99 -> powermac7_3
- qemu-system-ppc -M mac99,via=pmu -> powermac3,1
- qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2
The last one is one of the rare Macs that had adb and pmu, all others with
pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99
hardware but more similar to g3beige and no ADB ports according to
https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite
https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware
The PowerMac7,3 seems to be matching the PCI device listing in the comment
at the beginning of mac_newworld.c and also this article:
https://www.informit.com/articles/article.aspx?p=606582
What is the 2 USB devices problem? Is it the one we've debugged before and
found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c?
That could be fixed if there was somebody interested enough to provide a
patch.
But this series does not remove the mac99 and does not even deprecate it.
What it deprecates are the via option to select different machine types and
the automatic detection of ppc64 to emulate something different which are
hard to understand for users and caused several misunderstandings. It's
much more clear to have a separate machine type for each machine we emulate
even when they aren't yet complete but at least we know which way to go and
can compare to real hardware and fix the missing parts later. Also
introducing powermac7_3 to split the ppc64 mac99 would allow to remove
qemu-system-ppc if we wanted and only have one executable for all machines
but even without this it's clearer to have separate machnies for G5 and G4
macs than mac99 silently behaving differently.
Ultimately the issue you are trying to solve is this, which is that -M mac99
is different for qemu-system-ppc and qemu-system-ppc64. Perhaps the best way
to start is to create a new "g5niagara" machine type (including OpenBIOS) and
make it a clone of mac_newworld.c, and then issue a warning on
qemu-system-ppc64 for -M mac99.
I don't get what you mean. Patch 4 introduces a new machine type called
powermac7_3 (or g5niagara if you want) which is a clone of mac99 and then
issues the warning to deprecate qemu-system-ppc64 -M mac99 in patch 5. Did
you actually test these patches at all?
The reason for suggesting this is that the number of users of
qemu-system-ppc64 -M mac99 will be much smaller than those using
qemu-system-ppc, which means there will be a lot less breakage for users. In
Except those who mean to use ppc mac99 but think that they should use
qemu-system-ppc64 on 64 bit Windows which is probably the highest number
of users currently. I've cc'd you on the last instance of this but can dig
up some more from last year and look at the emaculation.com forum or ask
Howard how many times that happens. So after these patches users can still
use qemu-system-ppc -M mac99 as before without a warning but will get
warned for qemu-system-ppc64 -M mac99 to use powernac7_3 instead.
the meantime we don't need to make a final decision re: machine names, yet it
still gives you the freedom to work on -M mac99 for 32-bit Macs and move it
closer towards the G4 AGP model.
That's a different issue you're mixing in here. One issue is mac99
emulating different machines with ppc and pcc64, this is solved as above.
Another issue is that ppc mac99 is not a real mac, to get the hardware to
match the device tree OpenBIOS tells the guest it is you have to use
mac99,via=pmu which no user can guess. I want to rename this to simply
powermac3_1 and get rid of the via option eventually and make these
separate machines which is much more clear to the user. The implementation
remains the same, but we're free to change that later once the naming is
resolved. So I think we should decide on naming now and start deprecating
old names (which are ppc64 mac99 and macc99 with via option so we only
leave mac99 as before and all other variants will become -machine
options). What part of this is not clear to you. I feel like despite
trying to explain it for the third time we're still not on the same page.
Regards,
BALATON Zoltan
