From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29079 invoked by alias); 14 Nov 2009 00:12:24 -0000 Received: (qmail 29072 invoked by uid 22791); 14 Nov 2009 00:12:23 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx3.mail.elte.hu (HELO mx3.mail.elte.hu) (157.181.1.138) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 14 Nov 2009 00:12:19 +0000 Received: from elvis.elte.hu ([157.181.1.14]) by mx3.mail.elte.hu with esmtp (Exim) id 1N96Df-00021F-Rk from ; Sat, 14 Nov 2009 01:12:15 +0100 Received: by elvis.elte.hu (Postfix, from userid 1004) id 91CE63E22F6; Sat, 14 Nov 2009 01:10:22 +0100 (CET) Date: Sat, 14 Nov 2009 00:12:00 -0000 From: Ingo Molnar To: Roland McGrath Cc: Masami Hiramatsu , lkml , systemtap , DLE Subject: Re: [PATCH -tip 3/3] Add get_signal tracepoint Message-ID: <20091114001020.GB24738@elte.hu> References: <20091113225226.15079.90813.stgit@harusame> <20091113225240.15079.4863.stgit@harusame> <20091113235333.0E3CC15E8@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091113235333.0E3CC15E8@magilla.sf.frob.com> User-Agent: Mutt/1.5.20 (2009-08-17) Received-SPF: neutral (mx3: 157.181.1.14 is neither permitted nor denied by domain of elte.hu) client-ip=157.181.1.14; envelope-from=mingo@elte.hu; helo=elvis.elte.hu; X-ELTE-SpamScore: 0.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=0.0 required=5.9 tests=none autolearn=no SpamAssassin version=3.2.5 _SUMMARY_ X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q4/txt/msg00523.txt.bz2 * Roland McGrath wrote: > 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. ;-) I'd suggest to add include/trace/events/signal.h and put these tracepoints there. > 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: - signal generation events (send_sig*() variants) - signal IPI/wakeup events - signal loss events (queue overflow) - [ optional: signal blocking/unblocking events ] - [ optional: specific signal handler installation/deinstallation ] That's what we generally require of new events: they should form a coherent whole, a logical set of events that 'make sense' and explain the workings of a subsystem on a given level of detail. How finegrained or coarse the level of details is is an open question, but if a given level of detail has been picked, we want completeness on that level. So for example in the list above, the '[ optional ]' events are finegrained ones that could be left out of the initial version. We've done this consistently for all subsystems that added tracepoints: scheduling, locking, timers, workqueues, block IO, SLAB, IRQs, etc., and we want a similar approach for newly covered subsystems (such as signals) as well. Thanks, Ingo