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
