From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26217 invoked by alias); 26 Sep 2007 12:01:29 -0000 Received: (qmail 26207 invoked by uid 22791); 26 Sep 2007 12:01:27 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS,SUBJ_HAS_UNIQ_ID X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Sep 2007 12:01:20 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l8QC1I7x023014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Sep 2007 08:01:18 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l8QC1Gce025961; Wed, 26 Sep 2007 08:01:17 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l8QC1GjD026651; Wed, 26 Sep 2007 08:01:16 -0400 Received: from ton.toronto.redhat.com (ton.toronto.redhat.com [172.16.14.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 3C8ED8001FF; Wed, 26 Sep 2007 08:01:16 -0400 (EDT) Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id l8QC1G90023758; Wed, 26 Sep 2007 08:01:16 -0400 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id l8QC1Gbr023757; Wed, 26 Sep 2007 08:01:16 -0400 Date: Wed, 26 Sep 2007 13:54:00 -0000 From: "Frank Ch. Eigler" To: Roland McGrath Cc: systemtap@sources.redhat.com, utrace-devel@redhat.com Subject: Re: external systemtap meeting notes 20070816 Message-ID: <20070926120115.GT8964@redhat.com> References: <20070926084229.B17714D04B7@magilla.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <20070926084229.B17714D04B7@magilla.localdomain> User-Agent: Mutt/1.4.1i X-Virus-Checked: Checked by ClamAV on sourceware.org 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: 2007-q3/txt/msg00713.txt.bz2 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 925 Hi - On Wed, Sep 26, 2007 at 01:42:29AM -0700, Roland McGrath wrote: > [...] The future non-signal mechanism I described there can have a > reporting interface [...] The other part of the problem is > insertion/removal. Naive non-cooperation works if they literally > nest, but not if removal order is not LIFO. I don't have any > implicit-communication solution for that off hand. Yeah, this is roughly why we pointed out some time back that the utrace layer would be well situated to provide a high-level breakpoint-related API. What do you suggest in the interim? Would this hack work: have the second utrace engine refuse to put a breakpoint wherever it suspects another engine may have put one? Or even more pessimistically, can an engine know that another one is already monitoring a given target process, and give up at attach time? (That would defeat some of the promise of utrace, but so it goes.) - FChE --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFG+koLVZbdDOm/ZT0RAraVAJ9yeY945bd/q3M847WNFGsgcDzC/QCfWaCO BU9vg8XgUbG6C7yizLo17OA= =kcBv -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd--