[PATCH 6/8] ptrace: arch_ptrace -ENOSYS return

Roland McGrath roland at redhat.com
Thu Mar 20 19:16:58 EST 2008


> Hmm.. I see the whole series, and I see this patch, but I think it adds 
> new code and new complexity, and I don't really see *why*.

The motivation is to get the arch function out of the code path for the
machine-independent request handling.  I want to be able to change the
implementation later without touching the arch code again.  

The arguments passed down to arch_ptrace are sufficient for what the arch
code itself needs and for the current implementation in ptrace_request.
In future, I'd like the option of changing the code for the standard
requests to use a local data structure set up at the start of ptrace, and
such like (so more pointers and the like would need to be passed down to
ptrace_request).  These patches let me remove ptrace_request or change
its calling convention without touching the arch code again.

> Wouldn't it be nicer to just let "arch_ptrace()" return a flag saying 
> whether it handled things or not?

It would certainly be nicer.  I would prefer:

extern int arch_ptrace(struct task_struct *child, long request,
       	    	       long addr, long data, long *retval);

where it returns an error code or it returns 0 and *retval is the value
or it returns 1 and it didn't do anything.

The reason I took the approach I did instead is incrementalism.
I can't change that signature without breaking about 22 arch builds.
I'm only really prepared to thoroughly verify a change on 2 of those
myself.  It should be a simple enough change to make blind and get 
right.  But I've gotten a lot of things wrong before.  On principle,
I wouldn't really expect anyone to sign off on stuff I won't even
claim to have tried.  I did the forced_successful_syscall_return()
macro for arch's I don't try to build, and was just awful sure golly
that I hadn't got them wrong, because the generic change would break
those few arch's (not 20) without it.

So this ugliness seemed like a better bet than waiting for 20 more
arch sign-offs before any of it could go in.  You are certainly in a
position to just change the generic signature and make every arch do
the update (or fix your typos if you just tweak them all blind), and
let them grumble.  I did not presume to do so.

If you'd like a patch that changes this signature, updates all arch
implementations, and is actually verified to compile and work only
on x86 and powerpc, I'll be happy to provide that.


Thanks,
Roland



More information about the Linuxppc-dev mailing list