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