> I wanted to know if there was some actual technical point to it, and never 
quoted text
> got a reply to that. 

I thought I did answer that.  But I will again.  Yes, it's preemptive.
You won't gain anything right now.  That doesn't make it "churn for
churn's sake".  (For Pete's sake, you think I do this for fun?)

One of these days I will post substantial core ptrace changes.  I don't
know what these are yet, but I know it's likely they will need to change
what's passed between sys_ptrace and ptrace_request/ptrace_resume.  We
can expect that there will be churn in that code while we hash out how
it should be.  Doing this arch patch first means that none of that later
churn will involve changing arch_ptrace back and forth while the
non-arch code gets settled.

If this goes in early after 2.6.25, there will be ample opportunity to
hack on and hash out core changes with lots of flux and not worry about
arch conflicts.  Different people's versions can fall in and out of -mm
without juggling arch fixups in each variant, etc.  It's really for the
benefit of those of us who are exchanging lots of patches in this area
before they are ready for you to merge.

In short, it is cleaner if the arch calls only deal with the cases they
know how to handle, including knowing what the control flow or state
shared between pieces of non-arch code might be.  If you don't buy it,
fine.  Take it or don't.  The first time I have new code to submit that
is cleanest if it can break every ptrace_request caller, I'll make the
first patch in that series (maybe identical to this one) take arch_ptrace
out of the call graph for non-arch cases with the comment "so we never
have to break every arch_ptrace for arch-irrelevant changes *again*".


Thanks,
Roland
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/