From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30561 invoked by alias); 23 Dec 2009 20:56:27 -0000 Received: (qmail 30554 invoked by uid 22791); 23 Dec 2009 20:56:26 -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; Wed, 23 Dec 2009 20:56:22 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nBNKuKw3015571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Dec 2009 15:56:20 -0500 Received: from fche.csb (vpn-231-10.phx2.redhat.com [10.3.231.10]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nBNKuKhZ018212; Wed, 23 Dec 2009 15:56:20 -0500 Received: by fche.csb (Postfix, from userid 2569) id D931758114; Wed, 23 Dec 2009 15:56:19 -0500 (EST) Date: Wed, 23 Dec 2009 20:56:00 -0000 From: "Frank Ch. Eigler" To: Andre Detsch Cc: systemtap@sources.redhat.com Subject: Re: [PATCH] Update SCSI tapset Message-ID: <20091223205619.GA2785@redhat.com> References: <200912022012.53460.adetsch@br.ibm.com> <4B32681C.7010300@br.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B32681C.7010300@br.ibm.com> User-Agent: Mutt/1.4.2.2i 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/msg01019.txt.bz2 Hi - On Wed, Dec 23, 2009 at 04:57:32PM -0200, Andre Detsch wrote: > [...] Currently, the only usage example is > "testsuite/buildok/scsi.stp". It covers all tapsets/scsi.stp > probes. If it is good to have something inside > testsuite/systemtap.examples/io/, maybe moving or copying content > from testsuite/buildok/scsi.stp [...] We have heard interest in probe scripts that focus in on *errors*, specifically to display recent history of I/O up to the point of a low-level error associated with the device. Do you think you could write something like that? - FChE