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

[Oleg Nesterov]

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.

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?

> 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?

Oleg.