Bug 1138766

Summary:	eclipse-oprofile should use operf (opcontrol is being removed from oprofile-1.0.0)
Product:	[Fedora] Fedora	Reporter:	William Cohen <wcohen>
Component:	eclipse-linuxtools	Assignee:	Roland Grunberg <rgrunber>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	22	CC:	akurtako, chwang, extras-orphan, jerboaa, jjohnstn, krzysztof.daniel, mat.booth, mbenitez, mmcgrath, overholt, rgrunber
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-06-13 14:13:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description William Cohen 2014-09-05 15:17:19 UTC

Description of problem:  The upcoming release of oprofile-1.0.0 removes opcontrol.  The oprofile eclipse plugin should use operf instead if it is available.

An added bonus is for using operf is that this can be run as a normal user.  It can be easily run for the duration of a experiment with something like:

operf <command_to_run>

Comment 1 Alexander Kurtakov 2014-09-05 19:14:13 UTC

Roland, this is your area.

Comment 2 Roland Grunberg 2014-09-05 19:54:59 UTC

The eclipse-oprofile plugin being shipped in f20 should be using 'operf' by default (Linux Tools Project made operf the default in v2.2). Since then there should be some more usability fixes that have been made. There have also been some committers on Linux Tools Project wishing to remove support for opcontrol entirely given that future versions of oprofile will remove it, and this seems fine to me.

The only issue is we'd like have to break API to remove all support, and so we wouldn't be able to do that immediately.

I'd mark this as WORKSFORME unless there's a case on f20 or above where opcontrol is clearly being used by a default launch.

Comment 3 William Cohen 2014-09-05 20:23:30 UTC

I wasn't sure if this had been addressed already and figured it was better to file the bug and have it closed than to surprise eclipse users when opcontrol isn't available in oprofile-1.0.0.

For testing purposes there is a fedora scratch built of oprofile from its git repository at: http://koji.fedoraproject.org/koji/taskinfo?taskID=7515428

You could use the scratch builds to make sure there are no other problems lurking with the upcoming oprofile 1.0.0 release with respect to eclipse.

Comment 4 Roland Grunberg 2014-09-05 20:40:02 UTC

True, at the very least we can test to see how eclipse-oprofile behaves when a user attempts to change a launch configuration to use opcontrol. I'll look into this.

Comment 5 William Cohen 2014-09-17 19:27:24 UTC

The oprofile-1.0.0 is now in fedora rawhide, so it should be easy to verify that everything works as expected in fedora rawhide.

Comment 6 Roland Grunberg 2014-09-22 12:47:57 UTC

https://git.eclipse.org/r/#/c/33273/ from upstream should remove opcontrol as an option if it can't be located.

Comment 7 Jaroslav Reznik 2015-03-03 16:16:33 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 8 Roland Grunberg 2016-06-13 14:13:22 UTC

Marking as CLOSED (UPSTREAM) since the work for this was done at Linux Tools Project.