----- Original Message ----- > On 04/27, Dave Anderson wrote: > > > > > > OK, so we're running on a host machine that has one of these memory files > > > > that is accessible as a regular file. > > > > > > Yes, and this file is the physical memory of the guest. So it is essentially > > > the RAM dump which can be used by "crash PATH-TO-THIS-FILE@0" right now without > > > any patches. And in this particular case the offset is always zero. > > > > > > But not on x86-64, is_ramdump() insists on ramdump_to_elf() even if we could > > > use read_ramdump(), and ramdump_to_elf() doesn't support x86-64. > > > > Right, but that's a trivial fix, right? As I mentiond before, the only reason > > it doesn't support is because nobody's tried/asked/needed-to. > > Probably yes, I simply do not know. I know nothing about elf magic. It should simply be a matter of setting e_machine to EM_X86_64 in ramdump_to_elf(), and letting alloc_elf_header() do the rest. > > > And with x86_64 support put into place, at least the "non-live" file should be a considered > > a ramdump, right? > > Sure. But again, we do not even need to update ramdump_to_elf() and create > the elf header, read_ramdump() can work just fine. This is what 09/10 does. Right, I understand. But it would be preferable if "-o dumpfile" could still be used for use with the "non-live" file. > > > > And of course, you can't use this RAM dump in "live" mode (without these > > > changes). > > > > Right -- that's the rub here. The "live version of a dumpfile" is a hybrid that's > > never been considered before. > > Yes, so 10/10 is just a one-liner. But it depends on 1-7. Say, without 02/10 > memory_source_init() fails. Without 04/10 /bin/crash segfaults. > Right, but there should be no need for the "raw" distinction given that the "non-live" dumpfile is really just a "regular" ramdump, for lack of a better term (and with x86_64 support added). And yes, the 1-7 qualifiers (and probably a few others) are always going to be necessary for the "live-dump-hybrid". So, getting back to our original discussions, the handling of this hybrid-live dumpfile is the main issue. I don't like the re-use of unrelated definitions like MEMSRC_LOCAL, which was used back in the remote-access days if the vmlinux file was available on a remote machine but the dumpfile had been copied to the host machine running crash. But I still don't know what to call it so that it makes sense. And BTW, give that the live-dump-hybrid will still require a new dumpfile-type #define that can be plugged into the pc->flags MEMORY_SOURCES bitmask, I see now that the MEMSRC_LOCAL would be a great candidate to move from pc->flags to pc->flags2. Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
