I was working on improving documentation/structure of the upstream
kexec-tools and I was wondering what is the purpose of the 'kdump'
directory inside the kexec-tools.

This kdump utility seems to cause confusion with the 'kdump' utility
present inside some distributions (for e.g.  '/usr/sbin/kdump' present
inside fedora) due to the same naming convention and so we should
populate/modify the kdump man page to indicate the same, so as to
avoid confusion.

Presently here are the contents of this directory:

# ls kdump/
kdump.8  kdump.c  Makefile

- Out of these the kdump man documentation (kdump.8) is just a
placeholder as suggested by the man page documentation: "kdump - This
is just a placeholder until real man page has been written"

- Looking at kdump.c :

1. I understand that this code is mainly used to read a crashdump from
memory. One can run the same using:

# kdump <start_addr>

where start_addr is basically the start address of the core dump
(which can also be represented via the 'elfcorehdr' environment
variable being passed to the crash kernel which represents the
physical address of the start of the ELF header)

2. This tool needs READ_ONLY access to /dev/mem (so we need to set
CONFIG_STRICT_DEVMEM configuration option accordingly).

3. The code thereafter reads (via mmap) and verifies the ELF header.
Subsequently it reads (via mmap) the program header.

4. Then we collect all the notes and write on STDOUT all the headers
and notes found in the crashdump collected from memory.

So, as per my understanding even in absence of (more powerful) tools
like crash (or gdb), we can still go ahead and read the crashdump from
memory and display all the headers and notes present in the same on
standard serial out interface using this kdump utility.

This is probably a good to have feature for systems which have very
simple/minimal rootfs (and I see that a few arm32 systems seem to use
the same as well) or are low on memory availability.

Now, I wanted to confirm if the 'kdump' utility for reading crashdump
collected from memory is still needed (as the last commit is dated
back to 2016 and was done for arm32 systems). If yes, I can go ahead
and enhance the kdump man page to include the description given above
- so that it helps users understand how to run the tool.

Please share your opinions.


kexec mailing list

Reply via email to