From: Mark Wielaard <mark@klomp.org>
To: Andrew Cagney <cagney@redhat.com>
Cc: frysk <frysk@sourceware.org>
Subject: Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}
Date: Fri, 15 Jun 2007 09:05:00 -0000 [thread overview]
Message-ID: <1181898053.4482.28.camel@dijkstra.wildebeest.org> (raw)
In-Reply-To: <467149C9.8050509@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]
Hi Andrew,
On Thu, 2007-06-14 at 09:59 -0400, Andrew Cagney wrote:
> 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.
Yes, but those are implementation details. Not differences in public
interface are they?
> 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.
Yes, but my point is more that pre-mature refactoring at this point
seems not a good idea. We don't seem to have all the information yet.
But maybe you do have a clear picture already. I am trying to get an
idea what we would really gain from it at this point. Which api users do
you have in mind and what are they doing now through frysk.proc (or
directly through frysk.proc.ptrace and frsyk.proc.core) that would be
better modeled through the proposed properties-based package
abstractions?
> 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.
Are you sure they are "live"-properties and not just implementation
details of the ptrace-implementation? Can you give a list of variables
and methods you think aren't just ptrace implementation details, but are
properties of a LiveTask?
My main concern here is that we are abstracting cases for which there is
just one implementation at this point (or rather, just renaming the
specific implementations as if they are abstract properties) and that we
are better of waiting till we actually have multiple implementations
with shared properties to see how a properties based setup based on live
or dead looks like.
Cheers,
Mark
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-06-15 9:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-13 13:17 Andrew Cagney
2007-06-14 10:11 ` Mark Wielaard
2007-06-14 14:08 ` Andrew Cagney
2007-06-15 9:05 ` Mark Wielaard [this message]
2007-06-15 15:04 ` Andrew Cagney
2007-06-15 19:44 ` Mark Wielaard
2007-06-18 18:15 ` Andrew Cagney
2007-06-18 19:06 ` Mark Wielaard
2007-06-18 23:29 ` Andrew Cagney
2007-06-19 8:59 ` Mark Wielaard
2007-06-19 22:30 ` Andrew Cagney
2007-06-20 9:21 ` Mark Wielaard
2007-06-19 8:32 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1181898053.4482.28.camel@dijkstra.wildebeest.org \
--to=mark@klomp.org \
--cc=cagney@redhat.com \
--cc=frysk@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).