On 01/21, Andrew Morton wrote: > > ptrace is a nasty, complex part of the kernel which has a long history > of problems, but it's all been pretty quiet in there for the the past few > years. Well, yes, I'd say ptrace is "frozen". Nobody add new features/improvements, only bugfixes. > This leads one to expect that a rip-out-n-rewrite is a > high-risk prospect. So, quite reasonably, one looks for a good reason > for taking such risk. As it was already said, utrace was not created to just replace the current ptrace. However, speaking of ptrace, imho even ptrace-utrace is more flexible and allows to improve this api easily. Just for example, even attach and detach are not trivial to use from user-space when it comes to multithread tracees. A one-liner patch for ptrace-utrace can implement PTRACE_DETACH which doesn't need TASK_TRACED, it is easy to avoid the initial SIGSTOP from attach (which doesn't always work but strace/gdb relies on it). Of course, I do not profess this is not posible with the current implementation. But this will need more changes, and these changes will touch the code outside of ptrace.c. And in fact I think that any enhancements in this area will lead to rewrite of the current ptrace code. I must admit that personally I think the current ptrace api is unfixable, we need the new one in the long term. It would be nice to just kill ptrace, but this is not possible and that is why ptrace-utrace exists. And, if nothing more, utrace allows to have both old and new ones without any changes outside of ptrace/utrace code. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
