On 30/04/2024 1:54 pm, Roger Pau Monné wrote:
> On Tue, Apr 30, 2024 at 02:06:38PM +0200, Jan Beulich wrote:
>> On 30.04.2024 13:25, Roger Pau Monné wrote:
>>> On Tue, Apr 30, 2024 at 12:37:44PM +0200, Jan Beulich wrote:
>>>> On 30.04.2024 10:29, Roger Pau Monne wrote:
>>>>> @@ -301,21 +52,32 @@ static const char *const fs_names[] = {
>>>>> [XEN_SYSCTL_cpu_featureset_hvm_max] = "HVM Max",
>>>>> };
>>>>>
>>>>> -static void dump_leaf(uint32_t leaf, const char *const *strs)
>>>>> +static const char *find_name(unsigned int index)
>>>>> {
>>>>> - unsigned i;
>>>>> + static const struct feature_name {
>>>>> + const char *name;
>>>>> + unsigned int bit;
>>>>> + } feature_names[] = INIT_FEATURE_NAMES;
>>>>> + unsigned int i;
>>>>>
>>>>> - if ( !strs )
>>>>> - {
>>>>> - printf(" ???");
>>>>> - return;
>>>>> - }
>>>>> + for ( i = 0; i < ARRAY_SIZE(feature_names); i++ )
>>>>> + if ( feature_names[i].bit == index )
>>>>> + return feature_names[i].name;
>>>> ... a linear search, repeated perhaps hundreds of times, looks still a
>>>> little odd to me.
>>> I didn't benchmark what kind of performance impact this change would
>>> have on the tool, but I didn't think it was that relevant, as this is
>>> a diagnostic/debug tool, and hence performance (unless it took seconds
>>> to execute) shouldn't be that important.
>> As indicated, performance itself isn't much of a concern here. My earlier
>> question wants reading in relation to the other question raised, regarding
>> the script maybe wanting to produce macro(s) more suitable for the purpose
>> here.
> Hm, we could maybe produce an array of strings, one per feature bit
> (features without names would get NULL).
>
> I will see, albeit my python skills are very limited.
See how Xen's cmdline parsing uses feature_names; they're intentionally
sorted already.
But, having gen-cpuid.py write out something that's closer to what
xen-cpuid.c wants is also very easy to do.
~Andrew
