From: Igor Mammedov <imammedo@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: marcel@redhat.com, peter.maydell@linaro.org,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
qemu-devel@nongnu.org, alistair23@gmail.com
Subject: Re: [Qemu-devel] [PATCH v5 1/6] machine: Convert the valid cpu types to use cpu_model
Date: Tue, 18 Jun 2019 13:34:10 +0200 [thread overview]
Message-ID: <20190618133410.18b93bcd@redhat.com> (raw)
In-Reply-To: <20190617162700.GC19178@habkost.net>
On Mon, 17 Jun 2019 13:27:00 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Mon, Jun 17, 2019 at 05:33:43PM +0200, Igor Mammedov wrote:
> > On Mon, 17 Jun 2019 17:15:21 +0200
> > Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> [...]
> > > Yes. Eduardo and you should write some lines to explain this, and then
> > > we will follow :)
> > Unfortunately I don't recall details anymore. One could check out all
> > implementations of class_by_name callbacks to find out current state.
>
> See this message for a summary of existing class_by_name quirks:
>
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg615503.html
> Date: Wed, 08 May 2019 10:34:44 +0200
> Message-ID: <877eb173a3.fsf@dusky.pond.sub.org>
> Subject: Re: [Qemu-devel] [PATCH 0/7] Delete 16 *_cpu_class_by_name() functions
>
> I'm unsure about Igor's suggestion to get rid of CPU model names
> and use only QOM type names in external interfaces. In either
> case, we can still simplify the rules rules and reduce the amount
> of arch-specific code.
as far as we have cpu_class_by_name, we have to watch over that
new patches/targets won't add some custom handling/fallbac/whatnot.
On contrary -device works just with type names for all devices,
applying the same to -cpu which is basically translator
model->type[,-global type.foo,...]
would be consistent with -device and less confusing for everyone
(not counting significant code reduction).
It would certainly simplify contributing new targets as contributor
won't have to care about cpu model naming and do something about it.
This option wasn't considered before because we didn't have deprecation
back then, but now it opens possibility to simplify qemu and consolidate
naming. (we probably would be able to fold '-cpu help' into '-device help'
as well).
next prev parent reply other threads:[~2019-06-18 11:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-02 0:42 [Qemu-devel] [PATCH v5 0/6] Add a valid_cpu_types property Alistair Francis
2018-02-02 0:42 ` [Qemu-devel] [PATCH v5 1/6] machine: Convert the valid cpu types to use cpu_model Alistair Francis
2018-02-02 18:23 ` Eduardo Habkost
2018-02-05 11:22 ` Igor Mammedov
2018-02-05 13:54 ` Eduardo Habkost
2018-02-05 14:42 ` Igor Mammedov
2018-02-05 22:42 ` Eduardo Habkost
2018-02-06 14:43 ` Igor Mammedov
2019-06-17 5:09 ` Philippe Mathieu-Daudé
2019-06-17 14:43 ` Eduardo Habkost
2019-06-17 15:01 ` Igor Mammedov
2019-06-17 15:15 ` Philippe Mathieu-Daudé
2019-06-17 15:33 ` Igor Mammedov
2019-06-17 16:27 ` Eduardo Habkost
2019-06-18 11:34 ` Igor Mammedov [this message]
2019-06-18 13:55 ` Eduardo Habkost
2019-06-20 9:02 ` Igor Mammedov
2019-06-20 14:43 ` Eduardo Habkost
2020-01-23 18:48 ` Philippe Mathieu-Daudé
2020-02-06 20:59 ` Eduardo Habkost
2018-02-02 0:42 ` [Qemu-devel] [PATCH v5 2/6] netduino2: Specify the valid CPUs Alistair Francis
2018-02-02 0:42 ` [Qemu-devel] [PATCH v5 3/6] bcm2836: Use the Cortex-A7 instead of Cortex-A15 Alistair Francis
2018-02-15 13:23 ` Philippe Mathieu-Daudé
2018-02-15 22:41 ` Alistair Francis
2018-02-02 0:42 ` [Qemu-devel] [PATCH v5 4/6] raspi: Specify the valid CPUs Alistair Francis
2018-02-15 11:29 ` Peter Maydell
2018-02-15 13:04 ` Philippe Mathieu-Daudé
2018-02-15 13:17 ` Peter Maydell
2018-02-15 17:08 ` Igor Mammedov
2018-02-02 0:42 ` [Qemu-devel] [PATCH v5 5/6] xlnx-zcu102: " Alistair Francis
2018-02-02 0:42 ` [Qemu-devel] [PATCH v5 6/6] xilinx_zynq: " Alistair Francis
2018-03-13 23:13 ` [Qemu-devel] [PATCH v5 0/6] Add a valid_cpu_types property Philippe Mathieu-Daudé
2018-03-21 14:33 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190618133410.18b93bcd@redhat.com \
--to=imammedo@redhat.com \
--cc=alistair23@gmail.com \
--cc=ehabkost@redhat.com \
--cc=marcel@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).