From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25725 invoked by alias); 14 Nov 2009 00:02:52 -0000 Received: (qmail 25718 invoked by uid 22791); 14 Nov 2009 00:02:51 -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 mx2.mail.elte.hu (HELO mx2.mail.elte.hu) (157.181.151.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 14 Nov 2009 00:02:47 +0000 Received: from elvis.elte.hu ([157.181.1.14]) by mx2.mail.elte.hu with esmtp (Exim) id 1N9669-0005Pz-J1 from ; Sat, 14 Nov 2009 01:02:43 +0100 Received: by elvis.elte.hu (Postfix, from userid 1004) id 8D5053E22F6; Sat, 14 Nov 2009 01:02:35 +0100 (CET) Date: Sat, 14 Nov 2009 00:02:00 -0000 From: Ingo Molnar To: Roland McGrath Cc: Masami Hiramatsu , lkml , systemtap , DLE Subject: Re: [PATCH -tip 2/3] Add coredump tracepoint Message-ID: <20091114000234.GA24738@elte.hu> References: <20091113225226.15079.90813.stgit@harusame> <20091113225233.15079.41600.stgit@harusame> <20091113233912.192A3100E@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091113233912.192A3100E@magilla.sf.frob.com> User-Agent: Mutt/1.5.20 (2009-08-17) Received-SPF: neutral (mx2.mail.elte.hu: 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/msg00521.txt.bz2 * Roland McGrath wrote: > I can't really see what this has to do with "sched" to warrant that > name. But, whatever. That's a misnomer indeed. I'd suggest to introduce a separate 'signal' subsystem category. > Note that you put the tracepoint where it won't get called in the > various cases where no dump is really being made because of > RLIMIT_CORE or file failures. I suspect you would like to get those > reported. (Perhaps especially so, since there won't be any file > around to notice later.) Yeah, good point. > Also, it seems nice to give the tracepoint the chance to look at the > actual open file in case a fancy one wants to do that. Oh, so SystemTap is the motivator of these tracepoints? Do you know about exact usecases where these tracepoints would be utilized? Would be interesting (and relevant) to list them. Ingo