On 10/27, Roland McGrath wrote: > > 5/7 belongs first and I've already merged it as prerequisite to utrace. > We can send that upstream without delay. I hope it can get queued quickly > regardless of the review delays for the utrace and ptrace work.
Agreed, I'll send it to Andrew. > All the other "preparatory" patches are just to introduce PT_PTRACED as the > distinction between the obsolete hooks for old ptrace and the remaining > ptrace-specific kludges (unsafe_exec, tracer_task, and the interference > with SIGCHLD/wait semantics). Yes. And, although you didn't say this, I completely agree: this is dirty hack. > IMHO it's pretty questionable to do that > rather than test those statically such that under CONFIG_UTRACE the old > hooks are compiled away entirely (either via #ifdef or via things that > reduce to "if (0)"). Agreed! Hopefully we can do this later. As you understand, the goal is to make the first series as small as possible, where "small" means the number of changes outside of ptrace.c. > But moreover, this is fritter in the details of coexistence with the old > implementation or sequencing of phasing it out. I really have no idea > what the acceptable path for that is going to be at all. In the past, > upstream reactions have ranged from "utrace never!" to "no options, have > only the utrace-based ptrace exist at all". Yes. CONFIG_UTRACE should go away, but when this will happen? We have to fix !HAVE_ARCH_TRACEHOOK arches first and to ensure bobody in arch/ plays with ptrace internals. > I don't know that anyone is > positively in favor of conditionally having two ptrace implementations, At least, we don't have CONFIG_UTRACE_PTRACE. > I don't think we can answer that except in the actual upstream review. Yep. > So if this is v1 for upstream review, Yes, I hope so. Oleg.
