local vs remote; core vs exe vs ...

[Andrew Cagney <cagney@redhat.com>]

Hi,

Lets consider one possible way that the user may be allowed to interact 
with local/remote machines:

   (fhpd) load /bin/bash
   [0] /bin/bash
   (fhpd) load remotemachine:/bin/bash
   [1] remotemachine:/bin/bash
   (fhpd) [0] start
   [0] running /bin/bash
   (fhpd) [1] start
   [1] running /bin/bash on remotemachine
   (fhpd)

and:

    (fhpd) core remotemachine:/a/core/file
    [0] remotemachine:/a/corefile
    (fhpd) print i
    (fhpd) start
    [0] running /corefile/exe on remotemachine

and to specify a sysroot:

    (fhpd) load remote:/bin/bash -sysroot /local/ia32
    (fhpd) load /bin/bash -sysroot remote:/ia32

As always the questions are:

Does this look reasonable?  ...?

What are the consequences?

1.

At present frysk has a Host specialized for each possible type of Proc: 
core, exe, ptrace, utrace.  If a CoreProc needs to be created, the 
LinuxCoreHost is used; similarly, if a new process needs to be started 
then the LinuxPtraceHost is used.  The above interaction, however, 
suggests to me that perhaps the Host should be factored differently vis:

        Host
          - requestCreateProc - start a new process
          - requestProc - find a running process
          - requestCoreProc - create a Proc from the core
          - requestExeProc - create a Proc from the exe
          |
          +---------------------------.
          |                           |
      LocalHost                   RemoteHost
        o requestCoreProc
        o requestExeProc
          |
          +---------------------.
  LocalLinuxPtraceHost   LocalLinuxUtraceHost
    o requestCreateProc    o requestCreateProc
    o requestProc          o requestProc

This lets us implement an operation such as "start" directly, for 
instance: Proc.Host.requestCreateProc(Proc.exe).

2.

When it comes to performing searches such as for shared libraries and 
executables, in addition to the local/remote host, there is a "search" 
object, the sysroot, that resolves lookups for debug information.

Andrew