From: Markus Armbruster <armbru@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Igor Mammedov <imammedo@redhat.com>,
qemu-devel@nongnu.org, Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH 0/7] Delete 16 *_cpu_class_by_name() functions
Date: Wed, 08 May 2019 10:34:44 +0200 [thread overview]
Message-ID: <877eb173a3.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20190506195321.GB28722@habkost.net> (Eduardo Habkost's message of "Mon, 6 May 2019 16:53:21 -0300")
Eduardo Habkost <ehabkost@redhat.com> writes:
> On Mon, May 06, 2019 at 01:53:28PM +0200, Markus Armbruster wrote:
>> Eduardo Habkost <ehabkost@redhat.com> writes:
>>
>> > This series adds a new CPUClass::class_name_format field, which
>> > allows us to delete 16 of the 21 *_cpu_class_by_name() functions
>> > that exist today.
>>
>> Which five remain, and why?
>
> alpha_cpu_class_by_name:
> * Translates aliases based on alpha_cpu_aliases;
> * Falls back to "ev67" unconditionally
> (there's a "TODO: remove match everything nonsense" comment).
>
> cris_cpu_class_by_name:
> * Translates "any" alias to "crisv32" if CONFIG_USER_ONLY.
>
> ppc_cpu_class_by_name:
> * Supports lookup by PVR if CPU model is a 8 digit hex number;
> * Converts CPU model to lowercase.
>
> superh_cpu_class_by_name:
> * Translates "any" alias to TYPE_SH7750R_CPU.
>
> sparc_cpu_class_by_name:
> * Replaces whitespaces with '-' on CPU model name.
I'm of course asking because I wonder whether we can dumb down this CPU
naming business to something simpler and more regular.
Let's review what we have.
For all <TARGET> in target/*:
* arm i386 lm32 m68k mips moxie openrisc riscv s390x s390x tricore
unicore32 xtensa
CPU type name format is <TARGET>_CPU_TYPE_NAME("%s"), which boils down
to:
- arm lm32 m68k moxie riscv s390x tricore unicore32 xtensa
"%s-<TARGET>-cpu"
- openrisc
"%s-or1k-cpu"
- i386
"%s-x86_64-cpu" #ifdef TARGET_X86_64
"%s-i386-cpu" #else
- mips
"%s-mips64-cpu" #ifdef TARGET_MIPS64
"%s-mips-cpu" #else
The %s gets replaced by the user's cpu model.
* hppa microblaze nios2 tilegx
CPU type name format is <TARGET>-cpu. The user's cpu model seems
silently ignored.
* alpha cris ppc sh4 sparc
No format, using ->class_by_name()
- alpha
CPU type name format is "%s-alpha-cpu".
alpha_cpu_class_by_name() recognizes the full name, the full name
without "-alpha-cpu" suffix, and a bunch of aliases.
- cris
CPU type name format is "%s-cris-cpu".
cris_cpu_class_by_name() recognizes the name without the "-cris-cpu"
suffix, plus "any" as alias for "crisv32-cris-cpu" #ifdef
CONFIG_USER_ONLY (this is the default CPU type for machine
"axis-dev88"; the other machine "none" has no default).
- ppc
CPU type name format is
"%s-powerpc64-cpu" #ifdef TARGET_PPC64
"%s-powerpc-cpu" #else
ppc_cpu_class_by_name() recognizes the name without the suffix, plus
the CPU type's PVR (8 digit hex number), plus a bunch of (case
insensitive) aliases.
- sh4
CPU type name format is "%s-superh-cpu".
superh_cpu_class_by_name() recognizes the name without the suffix,
plus "any" as alias for "sh7750r-superh-cpu" (this is the default
CPU type for machine "shix"; machines "r2d" defaults to "sh7751r",
and "none" has no default).
- sparc
CPU type name format is
"%s-sparc64-cpu" #ifdef TARGET_SPARC64
"%s-sparc-cpu" #else
sparc_cpu_class_by_name() recognizes the name without the suffix,
mapping any spaces in the user's cpu model to '-'.
Observations:
* The CPU type name format is generally "%s-T-cpu", where T is either
<TARGET> or <TARGET>64.
Exceptions:
- openrisc, sh4 uses or1k, superh instead. Looks pointless to me.
- i386 uses x86_64 instead of i38664. Makes sense.
- hppa, microblaze, nios2 and tilegx use CPU type name format "T-cpu",
ignoring the user's cpu model. These exceptions looks pointless to
me.
* The user's CPU model is generally the "%s" part of the format.
Exceptions:
- alpha additionaly recognizes full type names. If that's useful for
alpha (I'm not sure it is), why isn't it useful for all other
targets?
- cris and sh4 additionaly recognize an "any" alias, cris only #ifdef
CONFIG_USER_ONLY.
Until PATCH 4, arm also recognizes an "any" alias #ifdef
CONFIG_USER_ONLY. PATCH 4 drops that, because it's redundant with
the "any" CPU, which is a copy instead of an alias. Sure we want to
do have different targets do "any" in different ways?
See aliases below.
- ppc additionaly recognizes PVR aliases and additional (case
insensitive) aliases. Feels overengineered to me. See aliases
below.
- sparc additionally recognizes aliases with ' ' instead of '-'.
Feels pointless to me. See aliases below.
* What about deprecating pointless exceptions?
* Aliases
We have several targets roll their own CPU name aliases code.
Assuming aliases are here to stay (i.e. we're not deprecating all of
them): what about letting each CPU type specify a set of aliases, so
we can recognize them in generic code?
next prev parent reply other threads:[~2019-05-08 8:35 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-19 6:14 [Qemu-devel] [PATCH 0/7] Delete 16 *_cpu_class_by_name() functions Eduardo Habkost
2019-04-19 6:14 ` Eduardo Habkost
2019-04-19 6:14 ` [Qemu-devel] [PATCH 1/7] cpu: Change return type of cpu_class_by_name() to CPUClass Eduardo Habkost
2019-04-19 6:14 ` Eduardo Habkost
2019-04-19 6:14 ` [Qemu-devel] [PATCH 2/7] riscv: Don't split CPU model string Eduardo Habkost
2019-04-19 6:14 ` Eduardo Habkost
2019-04-19 21:00 ` Alistair Francis
2019-04-19 21:00 ` Alistair Francis
2019-04-19 6:14 ` [Qemu-devel] [PATCH 3/7] arm: " Eduardo Habkost
2019-04-19 6:14 ` Eduardo Habkost
2019-04-19 6:14 ` [Qemu-devel] [PATCH 4/7] arm: Remove special case for "any" CPU model Eduardo Habkost
2019-04-19 6:14 ` Eduardo Habkost
2019-04-19 6:14 ` [Qemu-devel] [PATCH 5/7] cpu: Let architectures set CPU class name format Eduardo Habkost
2019-04-19 6:14 ` Eduardo Habkost
2019-05-06 11:42 ` Markus Armbruster
2019-05-08 5:52 ` Markus Armbruster
2019-04-19 6:14 ` [Qemu-devel] [PATCH 6/7] cpu: Set class name format for some architectures Eduardo Habkost
2019-04-19 6:14 ` Eduardo Habkost
2019-04-19 20:59 ` Alistair Francis
2019-04-19 20:59 ` Alistair Francis
2019-04-19 6:14 ` [Qemu-devel] [PATCH 7/7] cpu: Set fixed class name on " Eduardo Habkost
2019-04-19 6:14 ` Eduardo Habkost
2019-05-06 11:53 ` [Qemu-devel] [PATCH 0/7] Delete 16 *_cpu_class_by_name() functions Markus Armbruster
2019-05-06 19:53 ` Eduardo Habkost
2019-05-08 8:34 ` Markus Armbruster [this message]
2019-05-08 19:46 ` Eduardo Habkost
2019-05-09 5:55 ` Markus Armbruster
2019-05-09 15:46 ` 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=877eb173a3.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).