----- Original Message ----- > > But there is still no need to redundantly display the virtual and physical > > addresses. And the displays of the calculated file offsets, zero-fill, etc. > > will still end up showing the complete function sequence by putting the > > function name in the output. For example, the updated readmem() output would > > show a call to read_kdump(), but the file offset display would show that it > > has transitioned to read_netdump(), so there's no need for any debug output > > at all in read_kdump(). > > > Well, read_kdump() in the case of a non-hyper-mode XEN dump has code > that has the appearance of a route of change for paddr, i.e. the > following doesn't result in no change or in P2M_FAILURE: > > paddr = xen_kdump_p2m(paddr) > > The code I posted can show two unique paths through read_kdump() but if > as you say, you log calling it with the physical address known and log > in read_netdump() with the physical address included then you get the > same result. No, you're right -- that particular "switch" of the paddr value should probably have its own debug statement. > Also, are there any cases of overlapped/threaded execution of reads? > If not then removal of redundant output is wise but the virt/phys addr > would identify which thread of execution each line refers to among > overlapped output in most cases. Well, at least in the Xen case, yes it is possible. But they would be encapsulated by the debug statements that indicate the "temporary" change from read_kdump() to read_netdump() in x86.c, x86_64.c (and ia64.c). Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
