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

Linus Torvalds
2008-03-21T14:55:52Z

On Thu, 20 Mar 2008, Roland McGrath wrote:
>
> 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.

If there is no stronger motivation than that, then I don't want to have
this ugly and unnecessary complication.

I really don't see the advantage of doing

/* We can't handle it, let the generic code sort it out */
return -ENOSYS;

over a

/* We can't handle it, let the generic code sort it out */
return ptrace_request(child, request, addr, data);

in the arch-specific code, and I think the latter version is *much*
preferable if it avoids this whole unnecessary new abstraction crud and
odd testing in the generic part.

> The reason I took the approach I did instead is incrementalism.
> I can't change that signature without breaking about 22 arch builds.

Don't worry about the arch builds. If that's your main worry and reason
for this, it's not worth it. Yes, ptrace changes, and yes, we may have
arch issues, but no, it's not that big of a deal. Just break them.

Make sure x86[-64] works, and make sure that other architectures *can*
work (and explain it on linux-arch) when you have to fix something up, but
ptrace is a blip on the radar for people, it's not going to be a huge
issue.

> I'm only really prepared to thoroughly verify a change on 2 of those
> myself.

.. and you really aren't expected to. It's why we have architecture
people: if there is a good reason for the change (ie it's not just some
churn for churns sake), it's largely up to them to make sure the code
works.

Sure, you need to be able to explain the interface changes and answer
questions, but as mentioned, the ptrace code is not a big deal: it has
lots of tiny _details_, but it's not conceptually complex code.

> So this ugliness seemed like a better bet than waiting for 20 more
> arch sign-offs before any of it could go in.

Really, that has never been a major concern. I will _happily_ break the
odd architectures if I see that it's a matter of changing over some
detail (ie it's not some fundamentally hard issue for an arch maintaner to
fix up).

I think it's *wrong* to add a new an odd calling convention that is less
readable than what we have now, just to try to avoid something like this
that really isn't a big problem. It's not like we haven't broken
architectures over ptrace in the past, and it's also not like it's an area
that I think anybody has ever lost sleep over..

Linus