[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tricore default machine

From: Philippe Mathieu-Daudé
Subject: Re: Tricore default machine
Date: Mon, 10 Feb 2020 14:25:28 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 2/10/20 2:22 PM, Peter Maydell wrote:
On Mon, 10 Feb 2020 at 12:33, Bastian Koppelmann
<address@hidden> wrote:

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:
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
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.

Yes; we have default machines partly for historical reasons
and partly because x86 does, but unless there's a good
reason for some architecture why this specific machine
should be the default, I don't think we should have a default:
making the user specify what they actually want helps to nudge
them into thinking about what they do want, rather than
assuming that QEMU will somehow magically be able to run
guest images built for any random machine for the architecture.

OK now it makes sense.

Anything in tests or whatever that breaks if there's no default
machine for the architecture should be improved to handle that
(it already needs to handle that case, though: arm does not
have a defined default machine).

I tend to agree here.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]