On Wed, May 06, 2009 at 10:12:25AM +0200, Ingo Molnar wrote: > Yes. But realize the fundamental reason for that: _without_ > ptrace-over-utrace the utrace core code is a big chunk of dead code > only used on the fringes. I see and agree with all the future uses > of utrace, but it's easy to be problem-free if a facility is not > used by anything significant.
The ptrace cleanups might be required for utrace, but they by themselves don't make utrace any more useful without another user. > So a clean ptrace-over-utrace plugin is absolutely needed for utrace > to go upstream in v2.6.31. The ftrace plugin alone does not justify > it. The real prize here is a (much!) cleaner ptrace code. Once > ptrace is driven via utrace and it works, its value (and trust > level) will skyrocket. There are two blockers for utrace: - first all architectures need to be converted to the ptrace world order with regsets, tracehooks and so on. I hope we are on track to get this done now after I've pinged all arch maintainers. - we actually need a useful user of the utrace abstraction. And just converting ptrace to make it slightly more complicated by using another abstraction just isn't it. One useful bit that is in the queue is a in-kernel gdbstub for user process which would allow to get out of the ptrace and re-parenting mess for basic use cases. But a really convincing user would be even better. I don't think 2.6.31 is a very realistic target. While a lot of arch maintainers are working on their ptrace code 2.6.31 is just a too short deadline, and I'm also not sure we'll have the ptrace code in shape by then. 2.6.32 is much more realistic.
