Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [linuxtools-dev] oprofile on remote targets 
On 06/10/2011 02:21 PM, Siva Velusamy wrote:

Hi,

We'd like to include the oprofile plugins in an Eclipse based SDK that
we ship. However, we need to add support for remote targets in oprofile
since our focus is primarily on embedded targets. Browsing through the
archives, I see that a number of people have requested this feature, but
I'm not sure if someone is actively working on it. I plan to work on it
over the next couple of weeks, but I thought I'd get some feedback
before I start. I've summarized my understanding of the current status,
and what might be required to adapt the current sources for supporting
remote targets. I'd appreciate it if you could provide some feedback on
the proposal.



Hi Siva.
Good to hear you are interested in this. I am currently in the very early stages of looking at remote profiling. I started by looking at the remote Valgrind work done by Elliott Barron and getting it working. It uses TCF directly. One of the things I struggled with was getting the remote TCF set-up working which included installing an rpm on the remote system and launching the agent. I posted a few thoughts about this a while back on this mailing list. Some of the LTTng folks are interested in this as they use TCF as well and would like a way to launch TCF from the client-side Eclipse.
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. 


Current Status:

1. There is an existing contribution (in bugzilla) from ST that does
support remote targets. However, this contribution works in a very
different way than the Linuxtools oprofile plugins. In particular, it
directly parses the oparchive files, and as a result is very dependent
on the oprofile version. In my tests, it doesn't work with the oparchive
from oprofile 0.9.6. The code in bugzilla might be out of date though.
One nice thing about this approach is that the views are similar to
gprof, and it is nice to have some consistency.

2. The Linuxtools oprofile plugins don't have support for remote
targets, but the entire UI seems to operate out of the results from
opxml. As a result, it should be possible to support remote targets by
providing a way to launch oprofile on the target, and transferring the
XML files from the target back to the host.

Since I'm not too fond of parsing oparchive, I think it is easier to
modify the existing plugins than the ST plugin.

Proposed Changes:

At a high level, the current flow looks like this:

       oprofileShutdown();
       oprofileReset();
       oprofileSetupDaemon();
       oprofileStartCollection();

       DebugPlugin.newProcess();
       oprofileDumpSamples();
       oprofileShutdown();
       OpModelRoot.refreshModel()
       UiModelRoot.refreshModel()

The current code already abstracts away all the oprofile launching into
IOpcontrolProvider, and all the reading back of the XML into
IOpxmlProvider. So in theory, we need remote implementations for 3
functions:

1. IOpcontrolProvider
2. IOpxmlProvider
3. Ability to launch remote processes.

Since the target is anyways Linux, we should be able to reuse (or
refactor) most of the code from LinuxOpxmlProvider.

The specific questions I have are:

1. Am I overlooking something significant?


Seems reasonable at this point.


2. Am I correct in assuming that the OpModelRoot and UiModelRoot will
not need any changes?


I believe you are correct.


3. I also think that this should work fine on a Windows host, as long as
the binary is compiled on Windows (and debug symbols in the binary can
be mapped back to source).


OProfile is not on Windows.  What do you mean by this?


4. I was initially thinking of a custom framework to communicate to the
target, but a few recent threads on this list seem to indicate that this
should be done using TCF. I haven't used TCF before - if someone could
confirm that TCF is appropriate for this use case, that'll be greatly
appreciated.
That's the path we're currently heading down. It doesn't make sense to create a new framework. TCF is Open Source, extensible, and we already have proof of concept with remote Valgrind and LTTng. There are a number of areas that need to be cleaned up including set-up. In theory, we would have a special rpm that would install on the remote host. The rpm would install and run the agent as well as prereq various tools and install PolicyKit policy files. There's nothing to say we can't switch later to something else or allow other alternatives to TCF. 


5. I'm going to ignore all discussions regarding PolicyKit etc
initially. I assume that these proposed changes shouldn't significantly
impact future support for that.
It does have some bearing. The current code expects to find a special opcontrol executable/script in the native/scripts directory. This is currently set up by the install.sh script and right now uses consoleHelper which is being obsoleted. There is a bug to replace this with PolicyKit which is waiting on a CQ for approval. For running opcontrol remotely, we might as well call pkexec directly and specify /usr/bin/opcontrol. This assumes we have a policy file installed on the remote system which is part of the set-up design I was talking about earlier. 


Thank you for your feedback. I have initiated some discussions with our
legal team to make sure that we can contribute these changes back. If
someone is already working on this, please do chime in.




Regards,

-- Jeff J.




_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev

Back to the top