Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump
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.