From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
To: "Ahmed S. Darwish" <darwi@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>,
Maciej Wieczor-Retman <m.wieczorretman@pm.me>, <mingo@redhat.com>,
<dave.hansen@linux.intel.com>, <bp@alien8.de>, <hpa@zytor.com>,
<tglx@kernel.org>, <sohil.mehta@intel.com>,
<andrew.cooper3@citrix.com>, <linux-kernel@vger.kernel.org>,
<x86@kernel.org>, <john.ogness@linutronix.de>,
<ludloff@gmail.com>, <x86-cpuid@lists.linux.dev>
Subject: Re: [PATCH v2 2/2] x86/cpuid: Update bitfields to x86-cpuid-db v3.1
Date: Mon, 8 Jun 2026 11:22:30 +0200 [thread overview]
Message-ID: <aiaGHc8V4tLK-Rn4@wieczorr-mobl1.localdomain> (raw)
In-Reply-To: <aiZifD6RY4eTUimw@lx-t490>
On 2026-06-08 at 08:34:36 +0200, Ahmed S. Darwish wrote:
>On Thu, 04 Jun 2026, Ingo Molnar wrote:
>>
>> * Maciej Wieczor-Retman <m.wieczorretman@pm.me> wrote:
>> >
>> > Update leaf_types.h to version 3.1, as generated by x86-cpuid-db.
>> >
>>
>> The following detail from the first submission got lost:
>>
>> > @@ -246,7 +246,7 @@ struct leaf_0x6_0 {
>> > - thrd_director_nclasses : 8, // Number of classes, Intel thread director
>> > + hw_feedback_nclasses : 8, // Number of Intel Thread Director classes
>> >
>> > Note, for CPUID(0x6) thrd_director_nclasses, it was written this way
>> > because the project does not support bitfields names with more letters.
>>
>> What does this mean exactly, is there a string length limit on the
>> field name in 'struct leaf_0x6_0'? What is the limit?
>>
>
>Sorry, I should've made that more clear in the x86-cpuid-db release notes.
>Yes, there is a limit on field name lenghts so that the C headers formatted
>output is aligned and human readable. It's an implementation detail.
>
>After Maciej's patch:
>
> https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/commit/a7af01507814
>
>I searched for more typos, grammatical mistakes, etc. and fixed some:
>
> https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/commit/41380ff73e60
>
>Fixing thrd_director_nclasses name would exceed the project's field limit
>(23 characters), so I checked the manuals, and hw_feedback_nclasses was a
>better name anyway, and thus used it.
>
>That's the whole rationale.
>
>I guess this can be appened to the kernel patch changelog:
>
> Note, for CPUID(0x6) the "thrd_director_nclasses" field is replaced with
> "hw_feedback_nclasses" in this x86-cpuid-db release. Fixing the typo of
> the former would exceed the project's bitfield names chracter limit, and
> the latter name is more descriptive. See [link to x86-cpuid-db commit.]
>
>Thanks,
>Ahmed
Thanks for explaining :)
I thought the name change due to what was in the Intel manual was a better
rationale to put in the kernel patch log. The character limit seemed much more
specific to the cpuid-db project. But I suppose that information could be
benefical in case someone would want, in a kernel discussion, suggest a name
that's >23 characters.
I see the patches were already merged to tip but perhaps in the next release we
could put the character limit information in a comment somewhere in the
tools/arch/x86/kcpuid?
--
Kind regards
Maciej Wieczór-Retman
next prev parent reply other threads:[~2026-06-08 9:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-03 17:10 [PATCH v2 0/2] x86/cpuid: kcpuid: v3.1 x86-cpuid-db update with fixes Maciej Wieczor-Retman
2026-06-03 17:10 ` [PATCH v2 1/2] tools/x86/kcpuid: Update bitfields to x86-cpuid-db v3.1 Maciej Wieczor-Retman
2026-06-03 17:10 ` [PATCH v2 2/2] x86/cpuid: " Maciej Wieczor-Retman
2026-06-04 7:41 ` Ingo Molnar
2026-06-08 6:34 ` Ahmed S. Darwish
2026-06-08 9:22 ` Maciej Wieczor-Retman [this message]
2026-06-08 9:55 ` Ahmed S. Darwish
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=aiaGHc8V4tLK-Rn4@wieczorr-mobl1.localdomain \
--to=maciej.wieczor-retman@intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=darwi@linutronix.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ludloff@gmail.com \
--cc=m.wieczorretman@pm.me \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@kernel.org \
--cc=x86-cpuid@lists.linux.dev \
--cc=x86@kernel.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