|
From: Masami H. <mhi...@re...> - 2009-11-16 21:52:01
|
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: mhi...@re... |