----- 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.