Re: [PATCH 0/7] utrace-ptrace V1

2009-10-27 Thread 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



Re: [PATCH 0/7] utrace-ptrace V1

2009-10-27 Thread Oleg Nesterov
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.



Re: [PATCH 0/7] utrace-ptrace V1

2009-10-25 Thread Oleg Nesterov
On 10/26, Oleg Nesterov wrote:

 For early review.

 Patches 1-5 can be sent upstream right now. The last 2 patches
 add the new implementation.

 utrace.patch can come before or after, I think after is better.

Forgot to mention, this series is against Linus's tree.

Oleg.