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

[Dave Anderson]

----- Original Message -----
> sorry for delay Dave,
> 
> On 04/27, Dave Anderson wrote:
> >
> > > > > 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.
> 
> Yes, but afaics elf header buys nothing in this case, so it is not clear why do
> we need it if we can just use read_ramdump().
> 
> OK. Given that I confused you many times, can't we forget this for the moment
> and try to make the necessary changes step-by-step? I mean, lets discuss the
> LOCAL_ACTIVE() patches first, then return to RAM dumps.
> 
> > > 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.
> ...
> > 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).
> 
> OK, agreed.
> 
> > And yes, the 1-7 qualifiers (and probably a few others) are always going to be
> > necessary for the "live-dump-hybrid".
> 
> OK, good. So can't you apply 1-7 first? so that we can finish this part and then
> add the support for live dumpfiles.

No, I don't commit things piecemeal.  Once a patchset is completely acceptable,
I'll check it in.

> 
> 3/10 was buggy, I'll send v2 in a minute.
> 
> What else do you think I should change in this series?
> 
> Do you agree with 1/10? I mean do you agree with the name of new LOCAL_ACTIVE()
> helper and its semantics?

I'm beginning to agree...

> 
> > 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.
> 
> OK, good, so lets use MEMSRC_LOCAL at least for now. It should be trivial to change
> it later because only fd_init() uses this flag directly. Ignoring REMOTE() code, but
> they should not conflict.
> 
> > 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,
> 
> Yes, yes. And then we do not need to abuse CRASHBUITIN. But lets discuss this later.
> 
> 
> In short: what do you want me to change in 1-7 to get them applied?

The full patchset.

Dave