[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] Unified launcher for remote profiling?
|
On 11/14/2012 08:40 AM, Aleksandar Kurtakov wrote:
----- Original Message -----
From: "Anna Dushistova" <anna.dushistova@xxxxxxxxx>
To: "Linux Tools developer discussions" <linuxtools-dev@xxxxxxxxxxx>
Sent: Wednesday, November 14, 2012 12:22:15 PM
Subject: Re: [linuxtools-dev] Unified launcher for remote profiling?
Hi All,
On Tue, Nov 13, 2012 at 7:22 PM, Roland Grunberg
<rgrunber@xxxxxxxxxx> wrote:
I guess we could have plugins that can run remotely use the same
extension point, but some small changes would have to be made. I'm
not entirely familiar with all the details about remote profiling
as
I haven't touched it in a while, but assuming a project is already
set
up on some remote machine it should be possibe.
From that I take it as RDT is used as a default remote communications
framework, is that correct?
Right now remote run launcher/automatic remote debug launcher and
LTTng use RSE(which makes more sense in the embedded use case when
resources on the remote are limited to support native development
mode), and then there is also Target Explorer...
Are there any plans to standardize the remote communication mechanism
at least for the Linux Tools projects?
It's very painful for a user to set up 3 different connections to one
target to use 3 different tools.
I would love to see this standardised but it would need the attention of the various stackholders in order to happen. I can list many other areas where we(Linux Tools) fail on sharing code pretty badly.
For well known reasons - I would encourage using the lightest(fewer dependencies count!) and best integrated with the platform one. Linux Tools becoming a project that depends on everything under the sun doesn't make me happy.
AFAIK, the remote proxy infrastructure is supposed to be the
standardised way of enabling remote launch within linuxtools no matter
what technology you leverage for (i.e. ptp remote tools, rse, target
management, ssh...and so on). The proxy was designed to
1) Decouple linuxtools from other eclipse projects (ptp remote tools,
rse, targe management...etc)
2) Allow projects bundling linuxtools to choose whatever remote
technology they want to enable remote execution of the tools.
There are already implemented proxies of PTP remote tools
(org.eclipse.linuxtools.rdt.proxy), RSE (also in
org.eclipse.linuxtools.rdt.proxy) and SSH
(org.eclipse.linuxtools.ssh.proxy).
IMO, the remote proxy infrastructure still requires a nice polish.
However, it is important to say (so let community aware) it is ready
as-is and must be used by any developer wanting to add remote execution
support for any other linuxtools plug-ins..
Well, I know Rafael Medeiros and Jeff Johnson have implemented/used
linuxtools remote proxies...they are likely to have better accurate
information than I do. Here is just my 10 cents for the discussion.
Alexander Kurtakov
Red Hat Eclipse team
Thanks!
Anna.
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
