Messages in this thread | | | Date | Mon, 16 Nov 2009 18:45:44 -0500 | From | Masami Hiramatsu <> | Subject | Re: [PATCH -tip 3/3] Add get_signal tracepoint |
| |
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: mhiramat@redhat.com
| |