Re: Tricore default machine

[Bastian Koppelmann <kbastian@mail.uni-paderborn.de>]

On 2/10/20 11:26 AM, Thomas Huth wrote:
> On 10/02/2020 11.08, Philippe Mathieu-Daudé wrote:
>> On 2/10/20 10:35 AM, Thomas Huth wrote:
>>> On 07/02/2020 17.19, Philippe Mathieu-Daudé wrote:
>>>> The MachineClass is already zeroed on creation.
>>>>
>>>> Note: The code setting is_default=0 in hw/i386/pc_piix.c is
>>>>         different (related to compat options). When adding a
>>>>         new versioned machine, we want it to be the new default,
>>>>         so we have to mark the previous one as not default.
>>>>
>>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>>> ---
>>>> v3: new patch
>>>> ---
>>>>    hw/lm32/lm32_boards.c               | 1 -
>>>>    hw/lm32/milkymist.c                 | 1 -
>>>>    hw/m68k/q800.c                      | 1 -
>>>>    hw/microblaze/petalogix_ml605_mmu.c | 1 -
>>>>    hw/tricore/tricore_testboard.c      | 1 -
>>>>    5 files changed, 5 deletions(-)
>>> [...]
>>>> diff --git a/hw/tricore/tricore_testboard.c
>>>> b/hw/tricore/tricore_testboard.c
>>>> index 20c9ccb3ce..8ec2b5bddd 100644
>>>> --- a/hw/tricore/tricore_testboard.c
>>>> +++ b/hw/tricore/tricore_testboard.c
>>>> @@ -105,7 +105,6 @@ static void ttb_machine_init(MachineClass *mc)
>>>>    {
>>>>        mc->desc = "a minimal TriCore board";
>>>>        mc->init = tricoreboard_init;
>>>> -    mc->is_default = 0;
>>>>        mc->default_cpu_type = TRICORE_CPU_TYPE_NAME("tc1796");
>>>>    }
>>> I wonder whether we should simply make that machine the default for
>>> qemu-system-tricore? There is only one machine here, and not having a
>>> default machine always causes some headaches in the tests...
>>> (see e.g. tests/qemu-iotests/check for example)
>> Or make it generic? If a architecture has a single machine, use it by
>> default?
> Sounds like a good idea, too ... we've got a couple of targets that have
> only one machine.


As far as I remember, I did not make it the default machine, since Peter 
Maydell advised against it. His argument was that defaults are really 
hard to get rid off since external tools (like libvirt) might rely on 
the defaults and we don't want to break those. Anyways, no objections 
from my side.

Cheers,

Bastian