| Hi Alan,
There are two main approaches to remote enabling your plugin, depending on what you need to do:
a) If you need to run remote processes, manipulate remote files directly, etc., then you should start by looking at the APIs provided by org.eclipse.ptp.remote.core and org.eclipse.ptp.remote.ui (described below).
b) If you need to access files in a remote project (i.e. one set up using RDT), then you should always use the IResource interfaces for file manipulation and never use java.io.File (you should never use java.ui.File inside Eclipse anyway). If you use IResource then you can treat local and remote files in exactly the same manner as the EFS layer will hide everything from you. See the org.eclipse.core.resource documentation for more information.
You may also use a combination of both (a) and (b).
in PTP, the org.eclipse.ptp.remote.core plugin provides a range of abstract interfaces for manipulating remote "things":
IRemoteConnection - an abstract remote connection. Provides methods to open/close the connection, forward ports (aka tunneling), get the environment, get/set the working directory, etc. IRemoteProcess - an abstract remote process created by IRemoteProcessBuilder. Provides methods for getting the stdin, stdout and stderr streams. An IRemoteProcess is created using the IRemoteProcessBuilder interface IFileStore - an abstract remote file (provided by EFS). Has methods for file manipulation and obtaining input and output streams. An IFileStore is created using the IRemoteFileManager interface, or can be obtained directly from EFS if you know the URI.
There are also a range of interfaces and classes for UI related activities in org.eclipse.ptp.remote.ui. For example, there's a file browser for accessing files on the remote system.
These APIs work with either Remote Tools (which is a light-weight SSH provider in PTP) or with RSE (heavy weight provider that supports other protocols such as dstore and ftp).
There should be enough here to do what you want. If you have any questions, don't hesitate to ask.
Cheers, Greg On Aug 31, 2010, at 2:01 PM, Alan Humphrey wrote:
Hi all,
We're looking at remote-enabling the GEM plugin and wanted to ask a few
questions & get some input before we dig in. Any input would be
gratefully accepted. After looking at the PTP Wiki, it appears the way
PLDT is doing things is closer to the approach we need. Not sure how
much work remote-enabling GEM would take at this point, but we'd like
to get started.
Currently, the general chain of events GEM goes through is outlined in
the steps below:
Notes:
* Anything we "run" is via a java.lang.Process object and
Runtime.exec() to create a native process.
* We've been mostly using java.IO.File objects and relevant API calls.
* [Recap] ISP (In-situ Partial Order) is the underlying verification
tool for GEM. It requires no code instrumentation.
* We've created remote projects and tried running things knowing it
wouldn't work, but to see what did actually happen. GEM appears to
silently fail with remote projects. No NPEs, nothing.
Basic GEM chain of events
---------------------------------
1.) We run a script (a wrapper for mpicc) that compiles the project,
linking in MPI libs (e.g. libmpich, etc) and the interposition layer
library for ISP ( The Profiler - libispprof). This interposition layer
is needed to intercept MPI calls via the PMPI mechanism and
subsequently generate and force relevant schedules.
2.) Next we run ISP itself on the profiled executable. This does all
the dynamic verification for the profiled executable and generates a
log file (our own format currently).
3.) The log file generated by ISP is then parsed by GEM, allowing GEM
to display post verification results and source code stepping. GEM
relies on knowing the path to all the relevant source files for the
source code stepping we do in the Analyzer View.
Lots is happening under the hood with regard to organization, data
structures, etc, but in the context of remote-enabling GEM, it seems
like the relevant info is in the steps above. Once the log file is
generated, GEM simply needs access to it as well as the source files.
Should we consider the lighter weight approach taken by PLDT (using
IResource and getResourceURI(), pulling remote files back to the local
machine - we're not relying on any headers, etc at this point), or is
another approach to our problem more obvious to any who are more adept
at RDT and its inner workings than we are. I think we simply don't
understand the entire model very well at this point.
Thanks in advance for your time. I'll be joining the next PTP
conference call.
-Alan
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
|
