Messages in this thread | | | Date | Mon, 16 Nov 2009 16:51:23 -0500 | From | Masami Hiramatsu <> | Subject | Re: [PATCH -tip 3/3] Add get_signal tracepoint |
| |
Ingo Molnar wrote: >> Especially if you call this "get" rather than "deliver", there is >> another place that should invoke this tracepoint (or perhaps a third >> one). sys_rt_sigtimedwait "gets" a signal without delivering it. In >> POSIX terminology this is called "accepting" the signal: the three >> things that can happen in the life of a signal are "generate", >> "deliver", and "accept". If you are trying to match up what happened >> to a signal generated by kill() or whatnot, then you want to notice >> both delivery and acceptance as the complementary event. >> >> (And again I have no clue why this signal stuff should be called >> "sched" at all.) > > it shouldnt be called 'sched' - it should go into 'events/signal.h'. > > But we also need fuller coverage than this. Coredumps and signal > delivery events are just a small part of all things signals, we also > want:
That's a good idea. I'll put coredump and signal related events into events/signal.h.
> > - signal generation events (send_sig*() variants)
Those events finally calls __send_signal(), so I think trace_signal_send() can trace those events.
> - signal IPI/wakeup events
All signals might be used for IPI, isn't it? :-) Or, did you mean SIGSTOP/SIGCONT pare?
> - signal loss events (queue overflow)
Perhaps, this event is only for rt-signals, since legacy signals just overwritten if it was sent.
Thank you,
-- Masami Hiramatsu
Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division
e-mail: mhiramat@redhat.com
| |