IIRC, kernel/vmcore_info.c is never built as a module, as it also
accesses non-exported symbols.
Hello David,
I am looking again into this, and there are some things which in my
opinion would be difficult to achieve.
For example I looked into my patch #11 , which adds the `runqueues` into
kmemdump.
The runqueues is a variable of `struct rq` which is defined in
kernel/sched/sched.h , which is not supposed to be included outside of
sched.
Now moving all the struct definition outside of sched.h into another
public header would be rather painful and I don't think it's a really
good option (The struct would be needed to compute the sizeof inside
vmcoreinfo). Secondly, it would also imply moving all the nested struct
definitions outside as well. I doubt this is something that we want for
the sched subsys. How the subsys is designed, out of my understanding,
is to keep these internal structs opaque outside of it.
All the kmemdump module needs is a start and a length, correct? So the
only tricky part is getting the length.
One could just add a const variable that holds this information, or even
better, a simple helper function to calculate that.
Maybe someone else reading along has a better idea.
Interestingly, runqueues is a percpu variable, which makes me wonder if
what you had would work as intended (maybe it does, not sure).
From my perspective it's much simpler and cleaner to just add the
kmemdump annotation macro inside the sched/core.c as it's done in my
patch. This macro translates to a noop if kmemdump is not selected.
I really don't like how we are spreading kmemdump all over the kernel,
and adding complexity with __section when really, all we need is a place
to obtain a start and a length.
So we should explore if there is anything easier possible.
So I am unsure whether just removing the static and adding them into
header files would be more acceptable.
Added in CC Cristoph Hellwig and Sergey Senozhatsky maybe they could
tell us directly whether they like or dislike this approach, as kmemdump
would be builtin and would not require exports.
One other thing to mention is the fact that the printk code dynamically
allocates memory that would need to be registered. There is no mechanism
for kmemdump to know when this process has been completed (or even if it
was at all, because it happens on demand in certain conditions).
If we are talking about memblock allocations, they sure are finished at
the time ... the buddy is up.
So it's just a matter of placing yourself late in the init stage where
the buddy is already up and running.
I assume dumping any dynamically allocated stuff through the buddy is
out of the picture for now.
The dumping mechanism needs to work for dynamically allocated stuff, and
right now, it works for e.g. printk, if the buffer is dynamically
allocated later on in the boot process.
You are talking about the memblock_alloc() result, correct? Like
new_log_buf = memblock_alloc(new_log_buf_len, LOG_ALIGN);
The current version is always stored in
static char *log_buf = __log_buf;
Once early boot is done and memblock gets torn down, you can just use
log_buf and be sure that it will not change anymore.
To have this working outside of printk, it would be required to walk
through all the printk structs/allocations and select the required info.
Is this something that we want to do outside of printk ?
I don't follow, please elaborate.
How is e.g., log_buf_len_get() + log_buf_addr_get() not sufficient,
given that you run your initialization after setup_log_buf() ?
--
Cheers
David / dhildenb
