trace syscalls: Clean confusing {s,r,}name and fix ABI breakage
in [Kernel]
|
Prev: Revert "writeback: limit write_cache_pages integrity scanning to current EOF"
Next: Revert "writeback: limit write_cache_pages integrity scanning to current EOF"
From: Ian Munsie on 28 Jun 2010 21:10 Excerpts from Jason Baron's message of Thu Jun 24 04:03:54 +1000 2010: > overall this patch is a major improvement! My question though is > about the naming of the compat syscalls in the context of events. I > believe this patch differeniates compat syscall event names as: > "sys32_enter_sname", and "compat_sys_enter_sname". I agree that we keep that > distinction for purposes of defining the actual syscall function. However, > we had discuessed previously about keeping the event name the same for > all compat syscalls. ie they are all called "compat_sys_sname" or some > such. Reason being you could just do "compat_*" to match all compat > events. Sorry for the delay in replying - I've been pretty busy with other work over the last few days. I can certainly change that to name them all compat_sys to be more consistent. In terms of activating all of them at once that can still be done fairly easily since they are in their own compat_sys category with something like "perf record -e 'compat_syscalls:*' ..." or "echo 1 > /sys/kernel/debug/tracing/events/compat_syscalls/enable". Ideally I would actually like to consolidate these events with the ordinary syscall events and just print out compat=0|1 as part of their output. Since many of the native syscalls are used as compat syscalls as well I think that would make a whole lot more sense - at the moment to catch all syscalls from a compat process both the compat and native syscalls would need to be activated. It would also have the benefit of removing any arch specific naming from userspace, which would make things a lot nicer. Cheers, -Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |