On Wed, Apr 18, 2018 at 03:01:08PM +0200, Simon Horman wrote: > On Tue, Apr 17, 2018 at 10:01:13AM +0100, Russell King wrote: > > On Tue, Apr 17, 2018 at 10:20:08AM +0530, Bhupesh Sharma wrote: > > > Hi, > > > > > > 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. > > > > Firstly, please use: > > > > git://git.armlinux.org.uk/~rmk/kexec-tools.git > > > > for ARM systems - this has some important fixes that aren't in the > > mainline repository. > > I apologise if this is due to omission on my part, > can we work towards getting them in the mainline repository? The problem on ARM was caused because you applied the wrong version of the patches I sent out. When I noticed and reported it, there was no response. My only option over that intervening six months is to provide people with something that actually works properly on 32-bit ARM has been to publish my own kexec-tools git tree with the appropriate fixes in. It now contains a couple more patches than just fixing that up. If you want to merge from the above URL, be my guest, but as far as I'm concerned, it's been proven that sending patches for merging is open to mistakes happening. That wouldn't be too bad if it hadn't taken more than six months to get your attention on this issue. -- Russell King _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
