From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2238 invoked by alias); 14 Nov 2009 00:29:22 -0000 Received: (qmail 2231 invoked by uid 22791); 14 Nov 2009 00:29:21 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 14 Nov 2009 00:29:17 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAE0TFbx013415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Nov 2009 19:29:15 -0500 Received: from [10.16.2.46] (dhcp-100-2-46.bos.redhat.com [10.16.2.46]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAE0TEZ1006433; Fri, 13 Nov 2009 19:29:15 -0500 Message-ID: <4AFDF9DA.6090308@redhat.com> Date: Sat, 14 Nov 2009 00:29:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Roland McGrath CC: Ingo Molnar , lkml , systemtap , DLE Subject: Re: [PATCH -tip 3/3] Add get_signal tracepoint References: <20091113225226.15079.90813.stgit@harusame> <20091113225240.15079.4863.stgit@harusame> <20091113235333.0E3CC15E8@magilla.sf.frob.com> In-Reply-To: <20091113235333.0E3CC15E8@magilla.sf.frob.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00526.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. Agreed, I'll split them. > 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. ;-) Ah, I see. 'deliver_signal' is good to me :-). Thank you, > 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 > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division e-mail: mhiramat@redhat.com