Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [linuxtools-dev] Unified launcher for remote profiling?

On Wed, 2012-11-21 at 18:00 -0200, Wainer Moschetta wrote:
> 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.
> 

What I've got from this discussion so far is that the remote
infrastructure in Linuxtools is lacking. There are no standard in
plug-in names, unit testing can be improved and so on. I agree with
that, we can do better.

On the other hand, right now we have an unified local launcher that is
user friendly and polished, providing a better experience for the user.
This makes the remote capability looks deprecated and I',m afraid that
many users will "neglect" the remote support at all.

My point is that the user won't notice if there's any unit test missing
or any lack of standardization of the remote framework, but he'll sure
notice that there is no unified remote launcher. That said, I'll start
working on this unified remote launcher and cleaning up the remote
infrastructure on the process. Of course that this cleaning up will
continue after the unification, but at least we'll offer both remote and
local unified launchers to the user to play with.



- daniel 


> >
> >
> > 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
> >
> 
> _______________________________________________
> linuxtools-dev mailing list
> linuxtools-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
> 




Back to the top