[Crash-utility] [PATCH 0/5] Add support for Xen KDUMP files

[Dave Anderson]

----- Original Message -----
> On Thu, 24 Sep 2015 15:29:11 -0400 (EDT)
> Dave Anderson <anderson at redhat.com> wrote:
> 
> > ----- Original Message -----
> > > For many years, Xen dumps could only be saved in ELF format. Since
> > > makedumpfile commit 349a0ed1, it is also possible to save Xen dumps
> > > in KDUMP format, but it cannot be opened by the crash utility. This
> > > patch series adds support for these files.
> > 
> > Hi Petr,
> > 
> > I saw this coming down the pike a while ago, and as I recall you made it sound
> > like there would be major mods to diskdump.c.  But it's not much at all, so
> > thanks for that.
> 
> Glad to hear that you like the approach.
> 
> > I only have a couple minor nits with the patch-set:
> > 
> > I added xen_dom0.h to GENERIC_HFILES in the Makefile so that it would get
> > included in 'make files' (needed for creating the tar.gz and src.rpm files),
> > and to cause xen_dom0.c (and everything else for that matter) to get recompiled
> > if it changes.
> 
> Oh. I missed that. Sorry.
> 
> > And 'make warn' complained about these:
> >[...]
> 
> All right. I'll have to add "make warn" as one more step before submission.
> 
> > I removed the unused variables from netdump.c, and fixed the xen_dom0.c
> > complaints, which were generated because fprintf() is being used instead
> > of netdump_print().
> 
> Thank you!
> 
> > I ran a quick set of tests on a set of old xen files I've got hanging
> > around, and saw no problems.  But for sanity's sake, I'm going to run it
> > on my full set of dumpfiles overnight.
> > 
> > BTW, are you going to go ballistic on me if I check this in upstream as one patch?
> 
> It's easier to follow the logic of the changes in small steps. I
> believe it makes review easier for you (and everybody else on the
> mailing list). Regarding the repository - you are the maintainer, so
> please do whatever fits you best.
 
Right -- I completely agree with you regarding the logic and understandability 
of your multi-part patch set.  And because of that, I was just worrying that you might
consider it troublesome when it gets converted to the "one-patch-per-changelog-entry"
convention that I've been using.  

Anyway, nice job -- queued for crash-7.1.4:

  https://github.com/crash-utility/crash/commit/9531d0f551573a7e20a95c5d531452f53cc8a344

Thanks again,
  Dave