----- Original Message ----- > On 04/26, Dave Anderson wrote: > > > > > But all the LOCAL_ACTIVE changes in 1-7 do not care about the details of > > > "live" > > > mechanism at all. So I still think we need a generic helper which should > > > be true > > > if local-and-active. Or, vice versa, remote-and-active, this doesn't > > > matter. > ... > > > So you suggest to change this patch to do > > > > > > if (ACTIVE() && !ACTIVE_QEMU() && !INSTACK(...)) > > > > > > To me this simply looks worse, but I won't insist. But note that if we > > > ever have > > > another ACTIVE_SOMETHING() source, we will need to modify this code > > > again. While > > > this code do not care about qemu/something at all. So I still think we > > > need a new > > > helper which doesn't depend on qemu or whatever else. > > > > Right, but this is definitely the outlier with respect to "live" systems. > > Can't understand...
I mean that it's a special case of a "live" system. For the most part it is, but there are a number of gotcha's that would need to be caught and addressed. > > > > > > Or perhaps you mean that ACTIVE_QEMU() should be defined as > > > > > > > > > > #define ACTIVE_QEMU() (pc->flags2 & QEMU_LIVE) > > > > > > > > > > ? iow, it should not imply ACTIVE() ? This would be even worse, in > > > > > this case we > > > > > would neet to replace almost every ACTIVE() with "ACTIVE() || > > > > > ACTIVE_QEMU()". > > > > QEMU_LIVE should be in pc->flags, and appear as part of MEMORY_SOURCES. > > And LIVE_SYSTEM > > should also be set so that the facility falls under both ACTIVE() and > > ACTIVE_QEMU(). > > And then in the subset of cases where ACTIVE() is too broad, ACTIVE_QEMU() > > can be added > > as a restriction. > > OK. But not in the case above? This particular /proc/$tc->pid doesn't need to > know if this (remote) live system is ACTIVE_QEMU() or ACTIVE_SOMETHING_ELSE()? > All it needs to know if we debug the (live) kernel on the same machine or not. I think we're still talking about the code segment in back_trace()? All that is doing is recognizing that the "current" task no longer exists, and the backtrace attempt should fail. Then there's some other code that runs before the next "crash> " prompt that resets it to the live "crash" task that's running. In the live QEMU session, that will have to handled differently in both places. I don't know how you're going to easily determine whether task still exists. Dave -- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
