Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump
On 04/25, Dave Anderson wrote:
I see that your overloading the ramdump.c file, but the ramdump facility was
proposed and added by companies that use a firmware-based facility for dumping
raw ARM/ARM64/MIPS RAM into one or more ramdump files, typically because they
do/did not have kdump capability with their embedded hardware. I really don't
feel comfortable conflating that facility with a remote/live QEMU/KVM memory
source.
It's a pity ;) But this is minor.
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.
Those companies support it, and so any changes that you've added
to
ramdump.c should be accomplished elsewhere.
OK, we can add the new (say) --rawdump/livedump options and avoid any
changes in ramdump.c. Except probably 08/10 which can help to avoid
the code duplicating. But again, this is minor.
Also, we don't want to get this confused in any way with the
REMOTE_xxx
stuff.
Yes. And this series tries to not mess with REMOTE logic. And this is why
I didn't try to define LOCAL_ACTIVE() as (say) !REMOTE_ACTIVE().
At the same time, it tries to re-introduce the ability to debug the remote
live kernels. And the QEMU/KVM memory source is just the example.
And that is why I think we need 1-7. More on this in another email.
The remote.c file and remote access facility was deprecated many
years ago, but recently resurrected in crash-7.0.4 by Verizon specifically
for use like so:
OK, I see, thanks.
Anyway, this is a great idea, and one I've pondered in the past,
but is there a
concrete reason that it could not be a simple matter of plugging in a new function
into pc->readmem()?
Simply because read_ramdump() is already implemented and it does exactly we need.
And, say, "pc->flags2 |= RAMDUMP" makes sense too, display_sys_stats() will
use
show_ramdump_files().
Sure, it would be simple to write another plugin. The main problem is that there
is no room in pc->flags and that is why this series abuses CRASHBUILTIN ;)
Oleg.