[PATCH 0/7] utrace-ptrace V1

[Roland McGrath]

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.

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).  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)").

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".  I don't know that anyone is
positively in favor of conditionally having two ptrace implementations,
except perhaps as a compromise position for those who would prefer us to
jump in the lake and never propose utrace again.  I'm not at all sure
that there isn't any one of the people with de facto veto power who will
be dead-set against ever having both in the source at the same time.

I don't think we can answer that except in the actual upstream review.
So if this is v1 for upstream review, then take this path or whatever
other makes for the necessary fritter being easiest to read (which is
usually perceived upstream to mean least patch text) and get on with it.


Thanks,
Roland