> Two questions: > > 1. do you think this _can_ work as a first version of > utrace-ptrace? > > "work" means: could look as utrace-ptrace for 2.6.32, > then we make incremental changes on top.
I'm pretty doubtful. I'd like to hear other opinions, and I'm still 100% committed to "whatever works". But this direction doesn't look to me like something that any upstream reviewer would want to see. > This series adds the "fake" ptrace_utrace_ops. We never use these ops, > we only use engine to make stops/wakeups utrace-friendly. I see. This gives it a minimal level of ptrace/utrace cooperation, so it's better than plain utrace alone with the simple ptrace/utrace mutual exclusion logic, only in this one regard. Frankly I do not think that the inability to use utrace and ptrace simlutaneously on a task was significant in the upstream reaction to merging utrace with no ptrace reimplementation. This approach still lacks both a) cleaning up ptrace and b) exercising the utrace API via ptrace. I'm not at all sure this adds anything compelling over just submitting utrace alone and whatever non-ptrace users we could submit. So it's not necessarily bad. But I'm dubious it's of particular benefit to convincing people to merge utrace vs the status quo. My sense of why the ptrace revamp is important to upstream merging is that it demonstrates a) things wind up done more cleanly than before and b) the utrace API is proven adequate for something with well-worn real-world applications and known torture tests. > Signals. ptrace processes a signal after all other attached engines. As my reply to that patch indicated, what you can given the tracehook_get_signal API does not really fit that description. Perhaps by ignoring signr and looking at si_signo you could call it almost that. But still it's questionale. > Why? 2.6.32 is close. I doubt I can make the full-blown (and _working_) > implementation before the merge window. And I am nervous because I doubt. I share your concerns. But all we can do is try to produce things that really will get merged. If you are convinced that efforts on this new temporary kludge approach for ptrace make the difference in getting the utrace core merged into 2.6.32, then go for it. That seems unlikely to me, but I'm far from thinking I know what really does make that difference. Thanks, Roland
