On Thu, 27 Nov 2014 08:09:57 +0000 Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> wrote: > Hello Petr, > > >Hi all, > > > >during this year's SUSE HackWeek, my colleague started work on enabling > >kernel core files in gdb. I realized that there would be at least four > >different programs implementing read access to kernel dump files: > > > > 1. the crash utility > > 2. makedumpfile (when re-filtering) > > 3. kdumpid (my project to get kernel version from a dump file) > > 4. gdb-kdump (started by my colleague during HackWeek) > > > >At this point, I felt that's too much re-inventing the wheel again and > >again, so I took my current code from kdumpid and adapted it as a > >library that can be used by everybody: > > > > https://github.com/ptesarik/libkdumpfile > > I agree with you, your idea sounds reasonable. > > >In its current shape, it's usable, but far from complete. > > > >Things that work already: > > - identify kdump file format > > - parsed meta-information from the header > > - open ELF, diskdump, makedumpfile, LKCD > > - read data by physical address (incl. Xen Dom0) > > - read data by Xen machine address > > > >Things still on my TODO list: > > - more formats: sadump, kvmdump, libvirt, xc_core, xc_save > > - determine phys_base in ELF files > > - determine kernel release if not found in headers > > Aren't you going to make writer methods ? I thought about it, not the least because there are already at least three potential users of that functionality (makedumpfile, libvirt, and crash gcore extension). However, I probably need some help designing the API. Take makedumpfile as an example: the required actions depend on the output format (ELF header allocation), cyclic/non-cyclic, single file/multiple files, Xen/non-Xen... Streaming output should be possible somehow... Also, different output formats may offer different configurable options. This is not an issue when reading (the library hides these implementation details from the user), but there must be some API to specify the desired output format. I prefer a generic API, so that when more options are added, existing application continue to work, ideally even without recompiling. I'm sure all of the above can be done, but I haven't had enough time even to gather all requirements. In short, at this point, I welcome all ideas on how the writing API should look like. > If makedumpfile uses the library, I want to get rid of the dump format > specific codes completely from makedumpfile, otherwise "re-inventing" > will still occur. Agreed. On the other hand, drawing the line between filtering and writing is going to be a challenge. > I suppose that other tools don't need writer methods, so I think > it would be better if I make them. See above. Crash "gcore" extension writes dump files, libvirt has some support for writing dump files, and I'm sure there are quite a few other tools that generate a kernel/VM dump of some sort, and all of them might benefit from a standard API that allows them to use a wide range of output formats without additional effort. > >Ideally, I would like to replace all current implementations with > >this library, so if a new file format appears, or a new feature is > >added to one of the files, it can be immediately used by all > >kdump-related tools. > > > >Please let me know what you think. > >Oh, and if you're developing such a tool, let me know which features > >should be added. > > I've started an experiment to find out practical problems in switching > to using the library. I'll let you know if I find any problems. I'm curious. Petr Tesarik
