|
From: Masami H. <mhi...@re...> - 2009-11-16 23:46:00
|
Roland McGrath wrote: >> Hmm, actually, trace_signal_send() doesn't record the return value. > > Is that because it's called before the action really happens? > Is it important that it be called beforehand? If it's called > afterwards, it's easy to pass the return value. I'm not so sure why signal sending events was put beforehand. However, I assume that original intent might be recording the *timing* of all signal generation (including SIGSTOP/CONT). >> So, what about trace_signal_overflow() for RT-signals and >> trace_signal_loss_info() for non-RT? > > Really you can distinguish those just by looking at sig and info, so > perhaps a single tracepoint is enough. Ah, right :-) > I guess it really depends on what > filtering you would want and how inconvenient it is to have to apply that > filtering. Having these two distinct tracepoints lets you trivially trace > only "silent information loss" without seeing the events where userland > gets full information (if applications are paying attention). > > If you want to have a full suite of tracepoints where each one covers one > unambiguous corner of the semantics, then there are more than these just > for sending. e.g. see below. As Ingo said, I think this kind of finegrained events are optional. I don't think we really need these events soon. IMHO, just adding signal-loss event is enough at the first step. But anyway, thank you so much for suggesting those tracepoints! Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division e-mail: mhi...@re... |