Merging ptrace branch into mainline

From: Tejun Heo
Date: Fri Jul 22 2011 - 06:31:21 EST


Hello,

Most of the changes that I had on mind when I wrote "Proposal for
ptrace improvements"[1] seem complete. The details of course changed
quite a bit during implementation iterations but AFAICS all the
features and fixes described in the propsal are now in Oleg's tree
waiting to be pulled into mainline. New features are still blocked by
the DEVEL flag indicating the API is not finalized yet and should be
used only for developement.

Remaining issues are

* Two different modes of trap notification - directly ptrace_notify()
and force_sig(SIGTRAP), which makes SIGTRAP special w.r.t. ptrace.

There are two alternatives. One is converting SIGTRAP notifications
into (async) ptrace_notify() notifications. The other is to leave
it alone and just declare that SIGTRAP indeed is special and
userland programs playing with SIGTRAP won't behave transparently
while ptraced.

I haven't really looked at it too much but am currently leaning
towards the latter.

* Somewhat related. Some part of ptrace, especially breakpoint and
singlestep handling, is more arch-specific than necessary and archs
diverged on what is reported how. Most of this should be unifiable
or at least categorized.

Neither is very critical and we shouldn't be introducing drastic
userland visible behavior differences no matter which way we choose,
but given that this isn't an urgent thing, I think it would be best to
merge the pending ptrace changes with the DEVEL blocking enabled for
3.1, so that we can have more time settling down things and hopefully
seeing how it works with actual userland usage.

What do you guys think?

Thank you.

--
tejun

[1] http://thread.gmane.org/gmane.linux.kernel/1107045
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/