qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Harsh Prateek Bora <harshpb@linux.ibm.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	qemu-devel@nongnu.org
Cc: devel@lists.libvirt.org,
	"Daniel Henrique Barboza" <danielhb413@gmail.com>,
	"Cédric Le Goater" <clg@kaod.org>,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	qemu-ppc@nongnu.org, "Markus Armbruster" <armbru@redhat.com>
Subject: Re: [PATCH 1/2] target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming rules
Date: Fri, 12 Jan 2024 11:55:50 +0100	[thread overview]
Message-ID: <12a5e758-f144-40c2-bcb3-14855b81b7a4@redhat.com> (raw)
In-Reply-To: <54b6ba59-8edc-4b9c-bd3f-88399127f60e@linux.ibm.com>

On 12/01/2024 06.21, Harsh Prateek Bora wrote:
> 
> 
> On 1/12/24 10:42, Thomas Huth wrote:
>> On 12/01/2024 05.57, Harsh Prateek Bora wrote:
>>>
>>>
>>> On 1/11/24 22:16, Thomas Huth wrote:
>>>> The character "+" is now forbidden in QOM device names (see commit
>>>> b447378e1217 - "Limit type names to alphanumerical and some few special
>>>> characters"). For the "power5+" and "power7+" CPU names, there is
>>>> currently a hack in type_name_is_valid() to still allow them for
>>>> compatibility reasons. However, there is a much nicer solution for this:
>>>> Simply use aliases! This way we can still support the old names without
>>>> the need for the ugly hack in type_name_is_valid().
>>>>
>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>> ---
>>>>   hw/ppc/spapr_cpu_core.c |  4 ++--
>>>>   qom/object.c            |  4 ----
>>>>   target/ppc/cpu-models.c | 10 ++++++----
>>>>   3 files changed, 8 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
>>>> index 5aa1ed474a..214b7a03d8 100644
>>>> --- a/hw/ppc/spapr_cpu_core.c
>>>> +++ b/hw/ppc/spapr_cpu_core.c
>>>> @@ -389,9 +389,9 @@ static const TypeInfo spapr_cpu_core_type_infos[] = {
>>>>       DEFINE_SPAPR_CPU_CORE_TYPE("970_v2.2"),
>>>>       DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.0"),
>>>>       DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.1"),
>>>> -    DEFINE_SPAPR_CPU_CORE_TYPE("power5+_v2.1"),
>>>> +    DEFINE_SPAPR_CPU_CORE_TYPE("power5plus_v2.1"),
>>>>       DEFINE_SPAPR_CPU_CORE_TYPE("power7_v2.3"),
>>>> -    DEFINE_SPAPR_CPU_CORE_TYPE("power7+_v2.1"),
>>>> +    DEFINE_SPAPR_CPU_CORE_TYPE("power7plus_v2.1"),
>>>
>>> Will using Power5x, Power7x be a better naming than using 'plus' suffix ?
>>
>> The "x" looks like a placeholder to me, so it could be confused with 
>> power50, power51, power52, etc. ...?
>> But actually, I was thinking about using "power5p" and "power7p" first, so 
>> if the whole "plus" looks too long for you, would "p" be an option instead?
> 
> Hmm .. I would certainly vote for 'p' over 'plus'.

Ok, I don't mind either way ... does anybody else have any preferences?

  Thomas



  reply	other threads:[~2024-01-12 10:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11 16:46 [PATCH 0/2] ppc: Rename power5+ and power7+ for the new QOM naming rules Thomas Huth
2024-01-11 16:46 ` [PATCH 1/2] target/ppc/cpu-models: Rename power5+ and power7+ for " Thomas Huth
2024-01-11 17:24   ` Cédric Le Goater
2024-01-12  4:57   ` Harsh Prateek Bora
2024-01-12  5:12     ` Thomas Huth
2024-01-12  5:21       ` Harsh Prateek Bora
2024-01-12 10:55         ` Thomas Huth [this message]
2024-01-12 11:33           ` Cédric Le Goater
2024-01-12 15:47             ` Philippe Mathieu-Daudé
2024-01-11 16:46 ` [PATCH 2/2] docs/about: Deprecate the old "power5+" and "power7+" CPU names Thomas Huth
2024-01-11 17:25   ` Cédric Le Goater
2024-01-12 12:48 ` [PATCH 0/2] ppc: Rename power5+ and power7+ for the new QOM naming rules Peter Krempa
2024-01-17 14:05   ` Thomas Huth

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=12a5e758-f144-40c2-bcb3-14855b81b7a4@redhat.com \
    --to=thuth@redhat.com \
    --cc=armbru@redhat.com \
    --cc=clg@kaod.org \
    --cc=danielhb413@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=devel@lists.libvirt.org \
    --cc=eduardo@habkost.net \
    --cc=harshpb@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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).