On 02.05.2024 14:14, Andrew Cooper wrote:
> 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.
Sorted by name, when here we'd like to have it sorted by feature index.
Jan
