----- Original Message -----
On 04/28, Dave Anderson wrote:
>
> > OK, good. So can't you apply 1-7 first? so that we can finish this part and
then
> > add the support for live dumpfiles.
>
> No, I don't commit things piecemeal. Once a patchset is completely acceptable,
> I'll check it in.
OK. I will assume that so far you are mostly agree with 1-7.
> > In short: what do you want me to change in 1-7 to get them applied?
>
> The full patchset.
OK. So let me ask,
1. How the command line should look?
Well, for the non-live, crashed. version of this dumpfile, it should look exactly
as the current ramdump MEMORY-IMAGE@ADDRESS implementation, correct?
As for the "hybrid-live-dump" version, I'm not sure. So for now I guess you
can
continue using the "live:" prefix to the dumpfile name. If we come up with a
more logical naming scheme in the future, we can always change it later.
2. Should I re-use ramdump.c or should I just add the new file which
re-implements read_ramdump() ?
Given that these *are* essentially ramdump files, you've convinced me that ramdump.c
should be used.
When I was babbling on about creating a new file, I was still under the impression
that there was some kind of remote protocol going on. If I had been aware of exactly
what your "/tmp/MEM" file consisted of, and that it exists on the host machine,
I could
have avoided 80% of our back-and-forth emails. I'm really sorry for having wasted
your time.
Dave