this would go to a separate section called .tagged_memory.
That'd be confusing vs. actual memory tags, no?
Yeah, I came to the conclusion just after an upstream call we just had
about that topic (bi-weekly MM alignment session).
I'm open for any suggestions that make it more generic. My first
instinct was "named memory regions".
Maybe just "tagged_memory.h" or sth. like that? I'm bad at naming, so I
would let others make better suggestions.
inspect.h :)
I'm going to use 'inspect' as prefix for the thoughts below, but that's
obviously subject to s/inspect/$BETTERNAME/g :)
Then anyone can walk through the section and collect the data.
I am just coming up with ideas here.
Could it be even part of mm.h instead of having a new header perhaps ?
Then we won't need to include one more.
I don't really have something against a new include, just not one that
sounded like a very specific subsystem, not something more generic.
Right. We really don't want to have five different mechanisms for five
infrastructures which all allow to inspect kernel memory (life or
dead) in one way or the other. The difference between them is mostly:
- Which subset of the information they expose for inspection
- The actual exposure mechanism: crash dump, firmware storage,
run-time snapshots in a filesystem, ....
Having one shared core infrastructure to expose data to those mechanisms
makes everyones life simpler.
That obviously needs to collect the superset of data, but that's just a
bit more memory consumed. That's arguably significantly smaller than
supporting a zoo of mechanisms to register data for different
infrastructures.
I'm quite sure that at least a substantial amount of the required
information can be collected at compile time in special section
tables. The rest can be collected in runtime tables, which have the same
format as the compile time section tables to avoid separate parsers.
Let me just float some ideas here, how that might look like. It might be
completely inpractical, but then it might be at least fodder for
thoughts.
Thanks a bunch for writing all that down!
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.
@name:
Name of the memory region. That might go into a separate table
which is referenced by @id, but that's up for debate.
Jup.
@address:
@length:
obvious :)
...
Whatever a particular consumer might require
@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.
Though I might be wrong as usual. IOW this needs some thoughts. :)
The interesting engineering challenge with such a scheme is to come up
with a annotation mechanism which is extensible.
Runtime is trivial as it just needs to fill in the new field in the
datastructure and all other runtime users have that zero
initialized automatically, if you get the mechanism correct in the
first place. Think in templates :)
Compile time is a bit more effort, but that should be solvable with
key/value pairs.
Don't even waste a thought about creating the final tables and
sections in macro magic. All the annotation macros have to do is to
emit the pairs in a structured way into discardable sections.
Those section are then converted in post processing into the actual
section table formats and added to the kernel image. Not a
spectacular new concept. The kernel build does this already today.
Just keep the compile time annotation macro magic simple and
stupid. It can waste 10k per entry at compile time and then let
postprocessing worry about downsizing and consolidation. Nothing to
see here :)
Sounds interesting!
--
Cheers
David / dhildenb
