This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]