> I fully agree with the "kludge" above. :-)
> Yes sure. That is why I tried to talk about utrace notifications > "in general", not only about ptrace case. Ok, good. I saw only ptrace-specific things in that post so I wanted to be clear. > > So, how does the utrace module writer build that? You'd probably use > > wait_event() et al in your debugger thread, and wake_up() in report_* > > callbacks. > > OK. Is there anything else it might likely be? > Hmm. Except in this case ptracer can be running. It is not placed > on any wqh, but still needs a notification. Right. I remembered that having coffee this morning. Anyway, I really meant this to be the general-case discussion about utrace API features first and consider exact ptrace details a bit later. > > So how much is satisfied with a "delayed wake-up" (rather than an > > open-ended hook). Let's say: > > > > utrace_wake_up(task, engine, wqh); // replaces wake_up(wqh); > > return UTRACE_STOP; // | UTRACE_SIGNAL_IGN|UTRACE_SIGNAL_HOLD > > > > That would mean, approximately, as if wake_up(wqh) and then the wakee > > had called utrace_barrier(task,engine), but without the sched flutter. > > > > Formally, I think the guarantee should be "when utrace_barrier would > > return for you". Technically this means that if your callback did not > > use UTRACE_STOP, it's just sometime after your callback returns. But if > > you did use UTRACE_STOP, then it means after the task will definitely > > stop. > > This looks nice, but > > > That's all it means today, but I think we want to strengthen that > > guarantee so that when you have used UTRACE_STOP (either in a callback > > already in progress when you called utrace_barrier, or in a utrace_control > > call before the utrace_barrier call), utrace_barrier doesn't return until > > "utrace_prepare_examine will work", i.e. actually in TASK_TRACED/STOPPED. > > this means the meaning of utrace_barrier() should be changed? Right, there would be a new guarantee for utrace_barrier when you've used UTRACE_STOP on your engine. > A custom wake function can only be used if the wakee has already called > add_wait_queue(). Wake function belongs to wait_queue_t, not to > wait_queue_head_t. Yes, I know. > But this doesn't really matter. I think that using wait_queue_func_t->func() > (or whatever else we use to implement the utrace-delayed-wakeup) to do > ptrace-specific hacks is not better than engine->ops->special_hook(). > > In essence, this looks like we add another ->ops into engine implicitly. > > without > > needing anything but utrace_wake_up from the utrace layer. > > Not sure I understand how to implement this all :( You mean how to implement this utrace API inside utrace.c? That's OK for the moment. I meant to have us think through the API from the perspective of utrace module-writers (including ptrace) and reach a fairly firm idea of what API we'll be happy with before dealing with implementing it. I think it will be fairly straightforward along with some cleanups inside utrace that we wanted to consider anyway. Thanks, Roland
