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

On 04/26, Dave Anderson wrote: > > > But let me also say that there is nothing qemu-specific in this series. > > Except > > it happens to work with the recent memory-backend-file qemu option. > > > > I mean, you can just do > > > > $ dd if=/dev/crash of=RAMDUMP count=... > > > > and then > > > > $ crash path-to-your-vmlinux raw:RAMDUMP@0 > > > > or even just > > > > $ crash path-to-your-vmlinux live:/dev/crash@0 > > > > and this should work. Not that I think this makes sense, but should work. > > > > 9/10 and 10/10 just add the "raw:" and "live:" options. The 1st one means > > that crash should avoid avoid ramdump_to_elf()/read_kdump() and just use > > read_ramdump() to access this RAM dump. The 2nd one naturally tells that > > this memory is alive. > > I'm getting somewhat confused now. I was under the impression that this QEMU/KVM > concept for live systems only. No, > If you create a ramdump file that fits within the > constraints of the ramdump.c functionality -- essentially creating a "ramdump clone", > then yes, I guess I can understand why you would want to use ramdump.c. Yes. And to remind, MEMORY-IMAGE@ADDRESS (which is even documented in crash.8 as "raw RAM dumpfile that has no header information") doesn't work on x86-64, because ramdump_to_elf() fails with "unsupported machine type".

So imo 08/10 (which is the trivial preparation) and 09/10 make sense anyway, this doesn't need the previous LOCAL_ACTIVE patches. Yes, let me repeat that 09/10 asks for cleanup (the change in main.c). This is because I fail to understand this "if (is_ramdump())" block in main(), it looks simply wrong to me, but this is off-topic right now.

And can refactor these changes so that ramdump.c won't be changed at all, we can move these simple changes to the caller. > (as long > as it doesn't break compatibility with the aims of the embedded folks who > wrote it and use it). It shouldn't. As long they do not try to use a RAMDUMP file which name starts with "raw:" or "live:" prefix. > If we're *just* talking about supporting live system access of a QEMU/KVM guest, > then it should have nothing to do with ramdump.c. See above. But as for "live" ramdump's I do not see another use-case except qemu running with memory-backend-file.