From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17479 invoked by alias); 17 Jun 2009 19:02:27 -0000 Received: (qmail 17379 invoked by uid 22791); 17 Jun 2009 19:02:26 -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 mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Jun 2009 19:02:20 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n5HJ2Hxw023484; Wed, 17 Jun 2009 15:02:17 -0400 Received: from fche.csb (vpn-10-122.bos.redhat.com [10.16.10.122]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5HJ2GQB012516; Wed, 17 Jun 2009 15:02:16 -0400 Received: by fche.csb (Postfix, from userid 2569) id BE6D758446; Wed, 17 Jun 2009 15:02:15 -0400 (EDT) To: Josh Stone Cc: =?us-ascii?Q?=3D=3FISO-8859-2=3FQ=3FPrzemys=3DB3aw=5FPawe=3DB3czyk=3F?= =?us-ascii?Q?=3D?= , systemtap@sourceware.org Subject: Re: [PATCH] Fix target_set tapset. References: <1244936781.212635.16785@debian> <4A369CCD.60004@redhat.com> <40e92d5b0906161613m399497ecg89290c4687e01227@mail.gmail.com> <4A38449E.8060209@redhat.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Wed, 17 Jun 2009 19:02:00 -0000 In-Reply-To: <4A38449E.8060209@redhat.com> (Josh Stone's message of "Tue, 16 Jun 2009 18:19:26 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-q2/txt/msg00935.txt.bz2 Josh Stone writes: > [...] >> Death pid array is other solution, but clearing routine definitely >> shouldn't be located in target_set_report. [...] > > Now I think you're just messing with me, but ok, I see that death arrays > are making this overly complex. We should just decide whether the > records of dead pids should be kept around. It can be useful to remember the dead ones sometimes, but perhaps not for the purposes of this particular tapset, which is imagined to be useful for controlling future probes. If one wants the history too, a sibling tapset could be easily authored, with a target_set_history_report() function triggering its inclusion. Or make it all moot with PR6525. - FChE