[Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump

[Dave Anderson]

----- Original Message -----
> On 04/27, Dave Anderson wrote:
> >
> > > > OK, so we're running on a host machine that has one of these memory files
> > > > that is accessible as a regular file.
> > >
> > > Yes, and this file is the physical memory of the guest. So it is essentially
> > > the RAM dump which can be used by "crash PATH-TO-THIS-FILE at 0" right now without
> > > any patches. And in this particular case the offset is always zero.
> > >
> > > But not on x86-64, is_ramdump() insists on ramdump_to_elf() even if we could
> > > use read_ramdump(), and ramdump_to_elf() doesn't support x86-64.
> >
> > Right, but that's a trivial fix, right?  As I mentiond before, the only reason
> > it doesn't support is because nobody's tried/asked/needed-to.
> 
> Probably yes, I simply do not know. I know nothing about elf magic.

It should simply be a matter of setting e_machine to EM_X86_64 in ramdump_to_elf(),
and letting alloc_elf_header() do the rest.  

> 
> > And with x86_64 support put into place, at least the "non-live" file should be a considered
> > a ramdump, right?
> 
> Sure. But again, we do not even need to update ramdump_to_elf() and create
> the elf header, read_ramdump() can work just fine. This is what 09/10 does.

Right, I understand.  But it would be preferable if "-o dumpfile" could still be used
for use with the "non-live" file.

> 
> > > And of course, you can't use this RAM dump in "live" mode (without these
> > > changes).
> >
> > Right -- that's the rub here.  The "live version of a dumpfile" is a hybrid that's
> > never been considered before.
> 
> Yes, so 10/10 is just a one-liner. But it depends on 1-7. Say, without 02/10
> memory_source_init() fails. Without 04/10 /bin/crash segfaults.
> 

Right, but there should be no need for the "raw" distinction given that the
"non-live" dumpfile is really just a "regular" ramdump, for lack of a better
term (and with x86_64 support added).  

And yes, the 1-7 qualifiers (and probably a few others) are always going to be 
necessary for the "live-dump-hybrid".

So, getting back to our original discussions, the handling of this hybrid-live
dumpfile is the main issue.  I don't like the re-use of unrelated definitions
like MEMSRC_LOCAL, which was used back in the remote-access days if the vmlinux
file was available on a remote machine but the dumpfile had been copied to the 
host machine running crash.  But I still don't know what to call it so that it
makes sense.  And BTW, give that the live-dump-hybrid will still require a new
dumpfile-type #define that can be plugged into the pc->flags MEMORY_SOURCES bitmask,
I see now that the MEMSRC_LOCAL would be a great candidate to move from pc->flags
to pc->flags2.  

Dave