Re: [linuxtools-dev] oprofile on remote targets

[Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>]

On 06/10/2011 04:43 PM, Anna Dushistova wrote:
> 
> On Jun 11, 2011, at 2:36 AM, Siva Velusamy wrote:
> 
>> Thanks everyone for your responses. Jeff - see comments inline:
>>
>>     Anna has a good point in that we should use RSE.  I am going to
>>     open a bug to rewrite the Valgrind remote plugin to use RSE
>>     instead of calling TCF directly.  There is an RSE connector for TCF.
>>
>>     I would like to purse cleaning up the TCF remote launch as I feel
>>     that TCF is quite extensible and the current sample agent has
>>     pretty well everything we need as evidenced by the remote Valgrind
>>     work.  I want to change the design so it runs under a regular
>>     userid (instead of root as it does now).  To handle any required
>>     root access (such as opcontrol), the idea is to use PolicyKit
>>     pkexec and have policy files installed on the remote system for
>>     these special commands.  If we keep the design that installs an
>>     rpm on the remote system, this is straightforward to do.
>>
>>     I will open a bug for remote OProfile as well.  It would be great
>>     if you want to take on this work or collaborate.  I personally
>>     want to start on converting over the remote Valgrind plug-in to
>>     use RSE.
>>
>>
>> I haven't looked at the TCF/RSE integration, but from the emails it
>> sounds like RSE might sit on top of TCF and we should be using RSE for
>> all the remote target interaction. I'm certainly willing to
>> collaborate on this in the context of oprofile.
> 
> RSE(Remote Systems Explorer) supports different connection protocols
> including ssh and TCF. At the moment I don't envision anything in the
> oprofile plugin interaction with remote Linux target that requires some
> specific protocol.

I wonder about authentication when using PolicyKit.  Is there some way
that the user can authenticate via the command line, rather than going
through some sort of password prompting system?

Over the last day and a half, I've been playing with and debugging
TM.TCF, and was unpleasantly surprised at how robust it isn't (to put it
in a peculiar way).  For one thing, when setting up the agent, it
iterates looking through a large series of possibilities for rpms within
the tcf.debug.ui plugin, but there are *no* rpms in the current TCF
release, at least that I could find.  It also choked on the OS version
number 5.6, for RHEL 5.6 (the get-os-tag script converted it to 5_6 and
the Java code ran Integer.ParseInt() on that string, which threw an
exception).  Looking at the SVN updates to the TCF code, it doesn't seem
to have been actively developed in the last two years.  So I'm surprised
to learn that it's working for Valgrind and LTTng.  How did they manage
that without the rpms in the plug-in?

- Corey