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.
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?
2. Am I correct in assuming that the OpModelRoot and UiModelRoot will not
need any changes?
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).
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.
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.
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.
/Siva
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
