> I misunderstood the "UTRACE_INTERRUPT without UTRACE_EVENT(QUIESCE)" above
> as if you mean it is possible to get UTRACE_SIGNAL_REPORT without QUIESCE.
No, I meant the opposite: since you won't get UTRACE_SIGNAL_REPORT without
UTRACE_EVENT(QUIESCE), it might seem that UTRACE_INTERRUPT should not be
permitted, as UTRACE_REPORT is not. But because that is not it's *only*
effect, we don't do permit it even though you won't get UTRACE_SIGNAL_REPORT.
> OK. This means ugdb should set QUIESCE, just to ensure its ->report_signal()
> will be called.
If you ever want UTRACE_SIGNAL_REPORT calls, yes.
> OK, please forget. I must admit, this still looks a bit, well, unnatural
> to me. May be it makes sense to add
>
> _UTRACE_EVENT_SIGNAL_REPORT,
> _UTRACE_EVENT_SIGNAL_HANDLER,
>
> into utrace_events. Then ugdb could ask for UTRACE_SIGNAL_REPORT and
> avoid the unnecessary ->report_quiesce() calls.
If anything, I think UTRACE_EVENT(RESUME) would make sense, perhaps with a
separate ->report_resume callback. That would request only the cases that
now get report_quiesce(0). But, it really does not cost much to have
if (event) return UTRACE_RESUME;
or similar in your report_quiesce callback. It's beyond refinement of the
utrace API (that we're not doing now), it's just micro-optimization.
> Roland, could you also comment this patch?
>
> https://www.redhat.com/archives/utrace-devel/2010-August/msg00108.html
>
> Again, this looks like a bug to me, but I won't insist if it is not.
Sorry, that is still on my queue. I haven't forgotten it.
I just haven't gotten to reviewing it yet because of other
work and it needing a lot of hard thinking.
Thanks,
Roland
