Re: [RFC][PATCH v3 09/16] genirq/irqdesc: Have nr_irqs as non-static

[Thomas Gleixner <tglx@linutronix.de>]

On Wed, Sep 17 2025 at 21:03, David Hildenbrand wrote:
>> As this is specific for the compiled kernel version you can define an
>> extensible struct format for the table.
>> 
>> struct inspect_entry {
>> 	unsigned long	properties;
>>          unsigned int	type;
>>          unsigned int	id;
>>          const char	name[$MAX_NAME_LEN];
>> 	unsigned long	address;
>>          unsigned long	length;
>>          ....
>> };
>> 
>> @type
>>         refers either to a table with type information, which describes
>>         the struct in some way or just generate a detached compile time
>>         description.
>> 
>> @id
>>         a unique id created at compile time or via registration at
>>         runtime. Might not be required
>
> We discussed that maybe one would want some kind of a "class" 
> description. For example we might have to register one pgdat area per 
> node. Giving each one a unique name might be impractical / unreasonable.
>
> Still, someone would want to select / filter out all entries of the same 
> "class".
>
> Just a thought.

Right. As I said this was mostly a insta brain dump to start a
discussion. Seems it worked :)

>> @properties:
>> 
>>          A "bitfield", which allows to mark this entry as (in)valid for a
>>          particular consumer.
>> 
>>          That obviously requires to modify these properties when the
>>          requirements of a consumer change, new consumers arrive or new
>>          producers are added, but I think it's easier to do that at the
>>          producer side than maintaining filters on all consumer ends
>>          forever.
>
> Question would be if that is not up to a consumer to decide ("allowlist" 
> / filter) by class or id, stored elsewhere.

Yes, I looked at it the wrong way round. We should leave the filtering
to the consumers. If you use allow lists, then a newly introduced class
won't be automatically exposed everywhere.

Thanks,

        tglx