On 1/12/24 11:55, Thomas Huth wrote:
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(a)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?
p is fine.
Thanks,
C.