On Wed, Feb 03, 2010 at 03:42:05AM -0500, Mike Frysinger wrote: > On Tue, Feb 2, 2010 at 13:57, Christoph Hellwig wrote: > > While in theory user_enable_single_step/user_disable_single_step/ > > user_enable_blockstep could also be provided as an inline or macro there's no > > good reason to do so, and having the prototype in one places keeps code size > > and confusion down. > > the only annoying thing here is that we currently have to enable both > user_disable_single_step() and ptrace_disable() that do exactly the > same thing. i avoided this somewhat on Blackfin by cheating: > #define user_disable_single_step(child) ptrace_disable(child) > > so now there's no code bloat. perhaps this could be moved into common > linux/ptrace.h too ? What is done by most architectures is ptrace_disable simply calling user_disable_single_step. Long-term I expect ptrace_disable to go away entirely. While a few architectures do more than just user_disable_single_step in it that seems at least fishy to me, but I'll wait with the audit until we have everyone actually using ptrace_resume. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
