----- Original Message ----- > sorry for delay Dave, > > On 04/27, Dave Anderson wrote: > > > > > > > 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. > > Yes, but afaics elf header buys nothing in this case, so it is not clear why do > we need it if we can just use read_ramdump(). > > OK. Given that I confused you many times, can't we forget this for the moment > and try to make the necessary changes step-by-step? I mean, lets discuss the > LOCAL_ACTIVE() patches first, then return to RAM dumps. > > > > 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. > ... > > 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). > > OK, agreed. > > > And yes, the 1-7 qualifiers (and probably a few others) are always going to be > > necessary for the "live-dump-hybrid". > > 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. > > 3/10 was buggy, I'll send v2 in a minute. > > What else do you think I should change in this series? > > Do you agree with 1/10? I mean do you agree with the name of new LOCAL_ACTIVE() > helper and its semantics? I'm beginning to agree... > > > 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. > > OK, good, so lets use MEMSRC_LOCAL at least for now. It should be trivial to change > it later because only fd_init() uses this flag directly. Ignoring REMOTE() code, but > they should not conflict. > > > 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, > > Yes, yes. And then we do not need to abuse CRASHBUITIN. But lets discuss this later. > > > In short: what do you want me to change in 1-7 to get them applied? The full patchset. Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
