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