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. -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
