On 11/29, Dmitry V. Levin wrote: > > 2. Document these values sure, they should be documented and live in include/uapi/, > chosen to avoid collisions with ptrace_message values > set by other ptrace events this is what I can't understand. But to clarify, I don't really care and won't argue. If an application wants to use PTRACE_GETEVENTMSG to distinguish entry/exit (without PTRACE_GET_SYSCALL_INFO) it needs to do wait(status) and check status anyway, otherwise PTRACE_GETEVENTMSG is simply pointless (wrt syscall entry/ exit). So we do not care if PTRACE_EVENTMSG_SYSCALL_ENTRY conflicts with, say, SECCOMP_RET_DATA. > so that PTRACE_GETEVENTMSG users can easily tell > whether this new semantics is supported by the kernel or not. Yes. And how much this can help? Again, an application can trivially detect if this feature implemented or not, and it should do this anyway if it wants to (try to) use PTRACE_EVENTMSG_SYSCALL_ENTRY/EXIT ? Again, I won't reallly argue. But if you insist that these values must be unique then you probably need to add BUILD_BUG_ON(PTRACE_EVENTMSG_SYSCALL_ENTRY <= PID_MAX_LIMIT); ? OK, please forget... Oleg.
