----- Original Message ----- > Dave, sorry I need to run away. I'll reply tomorrow. And I need to > actually read your emails first, perhaps I misunderstood you... > > Just one note, > > On 04/25, Dave Anderson wrote: > > > > As I see it, this facility is simply another LIVE_SYSTEM memory source, > > of which there currently are /dev/mem, /proc/kcore and /dev/crash. The > > essential difference between them is the pc->readmem plugin: > > Well yes, to some degree... > > But let me repeat, I believe that crash needs something like 1-7 (and probably > more) anyway. Otherwise it can't work with remote LIVE_SYSTEM correctly. But the ACTIVE() macro has been the standard since forever, external extension modules depend upon it, etc., and so I'd strongly prefer to not change it to LOCAL_ACTIVE(). I'd rather keep the handling of this new facility segregated, maybe create something like an ACTIVE_QEMU macro/define that can be plugged in wherever you've modified the ACTIVE() callers where ACTIVE() alone is not enough. > And while I think that 10/10 can be useful by itself (and least for me), this > is mostly POC which which allows to test/justify these LOCAL_ACTIVE changes > in 1-7. OK good, so you can keep your stuff completely outside of ramdump.c, and not use is_ramdump(), etc., and then place as many of your changes as possible in a new file, say something like qemu-live.c. There may be redundancies between the new file and ramdump.c, but so be it. > > Oleg. > > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
