On Tue, 30 Jun 2020, Aleksandar Markovic wrote:
As, in a very clear way, evidenced from the previous versions of this
series, this series real goal was not not to create some new
"malta-strict" machine, but to prepare path to creation of some
imagined "malta-unleashed" machine which will, to the contrary of
proclaimed goal, create a machine that could never exist in reality.
That is why I can't accept this series.
I don't really want to be included in this discussion so please exclude me
from any replies, I can read replies on the list but don't want my mailbox
flooded with this thread. I could (and probably should) stay out of it but
maybe can offer some outsider view and share a suggestion.
I haven't followed all this thread but if your problem with it is that
something called malta should emulate that machine and not something
non-existent "malta-unleashed" then how about introducing a new machine
called virt which is a purely virtual machine? Arm has such a machine and
is recommended to be used for those who just want a generic Linux machine
without emulating any particular hardware. See here in docs:
https://wiki.qemu.org/Documentation/Platforms/ARM#Guidelines_for_choosing_a_QEMU_machine
I think Philippe was probably trying to do something like that with this
series which is clearly not forbidden by any QEMU policy as evidenced by
arm virt so maybe it's only a disagreement about how this should be named.
Keep malta to be modeling the Malta machine and add a new one called virt
which can be a copy of the current malta initially just to start from
somewhere (as arm was using versatilepb as mentioned above) but then the
directions these machines will be developed further could be different:
Malta would be developed to faithfully model the Malta machine, running
its firmware, etc. while virt could allow having more RAM or virtio
devices not available on real hardware. Why is that not acceptable?
Regards,
BALATON Zoltan
Regards,
Aleksandar
уто, 30. јун 2020. у 21:58 Philippe Mathieu-Daudé <f4...@amsat.org> је
написао/ла:
Hi,
This series add a new 'malta-strict' machine, that aims to properly
model the real hardware (which is not what the current 'malta'
machine models).
Since v2:
- Initialize missing malta_machine_types::class_size
- Remove RFC patch that confuses Aleksandar
- Added examples of 'malta-strict' use
$ git backport-diff -u v2
Key:
[----] : patches are identical
[####] : number of functional differences between upstream/downstream patch
[down] : patch is downstream-only
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively
001/5:[----] [--] 'hw/mips/malta: Trivial code movement'
002/5:[----] [--] 'hw/mips/malta: Register the machine as a TypeInfo'
003/5:[0001] [FC] 'hw/mips/malta: Introduce MaltaMachineClass::max_ramsize'
004/5:[----] [--] 'hw/mips/malta: Introduce the 'malta-strict' machine'
005/5:[----] [--] 'hw/mips/malta: Verify malta-strict machine uses correct DIMM
sizes'
Philippe Mathieu-Daudé (5):
hw/mips/malta: Trivial code movement
hw/mips/malta: Register the machine as a TypeInfo
hw/mips/malta: Introduce MaltaMachineClass::max_ramsize
hw/mips/malta: Introduce the 'malta-strict' machine
hw/mips/malta: Verify malta-strict machine uses correct DIMM sizes
hw/mips/malta.c | 105 +++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 91 insertions(+), 14 deletions(-)
--
2.21.3
