Hi All, may I ask why cannot this be done in a transport-agnostic way via RSE just like we do for remote launching/debugging in org.eclipse.cdt.launch.remote?
Just curious. Thanks! Anna. On Jun 10, 2011, at 10: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. > > 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 _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
