From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24229 invoked by alias); 14 Jun 2007 13:59:39 -0000 Received: (qmail 24219 invoked by uid 22791); 14 Jun 2007 13:59:37 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,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.31) with ESMTP; Thu, 14 Jun 2007 13:59:27 +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 l5EDxNgo023801; Thu, 14 Jun 2007 09:59:23 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l5EDxMs5012529; Thu, 14 Jun 2007 09:59:22 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l5EDxLxT021133; Thu, 14 Jun 2007 09:59:21 -0400 Message-ID: <467149C9.8050509@redhat.com> Date: Thu, 14 Jun 2007 14:08:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Mark Wielaard CC: frysk Subject: Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} References: <466FED51.3030804@redhat.com> <1181815036.4474.23.camel@dijkstra.wildebeest.org> In-Reply-To: <1181815036.4474.23.camel@dijkstra.wildebeest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00273.txt.bz2 Mark, Good questions. The key difference is that a dead system has no state (well, ok, only one) where as a live system is statefull and consequently, a dead system has no reason to implement or handle abstract methods such as sendrecContinue et.al where as a live system does. Over time we'll accumulate other "live" hosts - utrace, remote, and then when we've a problem, we'll with new information available, likely review how to better break down the "live" case. This further refinement, and introduction of frysk.proc.live.LiveTask lets us finish the refactoring task I started of separating out specific implementations of a Host (corefile, ptrace) from the abstract model. For instance, those state variables in frysk.proc.Task and corresponding methods can be localized to frysk.proc.live. Andrew Mark Wielaard wrote: > On Wed, 2007-06-13 at 09:12 -0400, Andrew Cagney wrote: > >> This picks up an earlier refactoring, where the specific instances of a >> Host et.al. were moved to sub-packages. As I noted back then, the >> sub-package names, in hindsite, weren't the best choice - reflecting >> implementation (using ptrace) rather than properties (live or dead). >> >> The intent is to rename frysk.proc.{ptrace,corefile} -> >> frysk.proc.{live,dead} >> > > Could you explain a bit more what kind of public interface (differences) > you see between these two packages? How would it compare with the public > frysk.proc interface for Tasks? > > My feeling is that it isn't a good idea to just rename the > implementation packages ptrace, corefile to these properties you find > more appealing. You should layer the properties on top of the > implementation techniques. > > There might be more implementations later like utrace and/or some > userspace /proc implementation layered on top of utrace that Chris is > working on. But we will still use ptrace for systems that don't support > utrace (yet). And with some magic we can probably give the core file > implementation some of the live properties by emulating memory, register > access and instruction stepping. So multiple implementations might map > to different instances of these properties. > > Cheers, > > Mark >