This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -tip 3/3] Add get_signal tracepoint
- From: Roland McGrath <roland at redhat dot com>
- To: Masami Hiramatsu <mhiramat at redhat dot com>
- Cc: Ingo Molnar <mingo at elte dot hu>, lkml <linux-kernel at vger dot kernel dot org>, systemtap <systemtap at sources dot redhat dot com>, DLE <dle-develop at lists dot sourceforge dot net>
- Date: Fri, 13 Nov 2009 15:53:33 -0800 (PST)
- Subject: Re: [PATCH -tip 3/3] Add get_signal tracepoint
- References: <20091113225226.15079.90813.stgit@harusame> <20091113225240.15079.4863.stgit@harusame>
This is orthogonal to the core-dump tracepoint, I don't see why you
call them a unified patch series.
The proper name for this event is "signal delivery". But since the
proper name for "send_signal" is "signal generation", I suppose "get"
is analogously improper to the existing "send" tracepoint. ;-)
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.)
Thanks,
Roland