> Not sure I understand how this connects to utrace_wake_up(). It doesn't.
> Yes, the signal sending is problematic, but wait_chldexit also looks > problematic. How can utrace_wake_up() know which wait_queue_head_t should > be used for wake up? It doesn't know anything like that. The ptrace callback passes an argument, like any other would. > Let's talk about API visible to engine writers. Which arguments > should utrace_wake_up() have, wait_queue_head_t ? When this > helper should be used by engine writers? The example was a single wait_queue_head_t * argument. It's used by an engine callback whenever you would otherwise write wake_up(), but want it to happen after the utrace callbacks and stopping are done. > Sure, the tracer and tracee can have many reasons to synchronize. > They can engine->data to place wait_queue_head_t. Or they can > use another wq. I still can't understand what a simple wrapper > on top of __wake_up() can buy us. It calls wake_up() after all utrace bookkeeping is done and the task is in already in TASK_TRACED. That's the sole point of the idea. Let's table further details on this for now. I never intended that we should resolve these questions before you are dealing with these problems concretely in working on a utrace engine. Thanks, Roland
