Speaker
Description
We would like to be able to select chunks of kernel memory for inspection or debug dumping, but only the essentials, such that we can create a core image, inspect the status of the kernel and vital information, without creating a full core dump, due to memory and time constrains.
Multiple patch series have been proposed, in which meminspect (or previously named kmemdump) API can be used to select parts of kernel memory for a generic inspection table generation. How can that be done in such a way that it will not bring overhead, not clutter the kernel code, be lightweight and easy to disable/enable, but still achieve its goal ?
This talk brings forth the pros and cons of different types of approaches, considering different types of memories that the kernel uses: static variables, global exported symbols, or dynamically allocated memory. The discussion then would circle around possible solutions to integrate the annotation of such memory in the kernel, with the aim of finding consensus with the kernel maintainers for the best possible option to achieve the desired goals.
As the hardware and firmware evolve, the kernel evolution must match the pace, but the selected solution needs to engulf all the requirements from existing users and devised for the future users as well.