> I've read through most of the docs (although my eyes certainly glazed > over when I got to the tracehook stuff).
That stuff is for kernel maintainers, as it says. You don't really need to know. For that part, just checking for typos is all the help it needs. > What's there seems to be pretty good. I think it is missing (or at > least I missed it) a good description of how to asynchronously stop a > thread. What are the ins-and-outs here, knowing how/when to use > UTRACE_STOP vs. UTRACE_INTERRUPT, etc. Yeah, the kerneldoc-driven format doesn't lend itself to a lot of exposition. The details are in there in the utrace_control description. But I guess it's not real obvious how to put it all together. How is the "Stopping Safely" section? That seems like the place to add something more direct about this. Was there something other than the UTRACE_INTERRUPT issue that didn't seem clear? Is that not clear to you, or is it just not clear in the documentation? You use UTRACE_INTERRUPT when you want to interfere with system calls in progress (or blocking page faults or whatever). To interrupt and stop (like PTRACE_ATTACH does) and handle it already being stopped, you really want to do UTRACE_STOP first and see 0 if it's already stopped. If it's not already stopped, you get -EINPROGRESS and then can do UTRACE_INTERRUPT to be sure that you interrupt it and that the race complexity of it being stopped before or waking up is minimized. (If you just do UTRACE_INTERRUPT first, then you'll get a callback soon--unless it's stopped. Then you won't, but if you do UTRACE_STOP second to see if it's stopped, then you could get the callback in between and your life gets more hairy.) I sure wouldn't mind any help writing more text for this. Hack at Documentation/DocBook/utrace.tmpl and send me a diff. Thanks, Roland
