Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Andrew Cagney <cagney at redhat dot com>]

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
>