Bug 250959 - The xenoprof patch define conflict with defines in oprofile 0.9.3
The xenoprof patch define conflict with defines in oprofile 0.9.3
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Markus Armbruster
Martin Jenner
Depends On: 250852
  Show dependency treegraph
Reported: 2007-08-06 01:51 EDT by Markus Armbruster
Modified: 2008-01-31 11:56 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-31 11:56:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Markus Armbruster 2007-08-06 01:51:11 EDT
+++ This bug was initially created as a clone of Bug #250852 +++

Description of problem:

The xenoprof patch adds some defines to oprofile/daemon/opd_interface.h.
Unfortunately, these defines conflict with the defines added for the Cell
processor in oprofile 0.9.3:

#define SPU_PROFILING_CODE              11
#define SPU_CTX_SWITCH_CODE             12

Version-Release number of selected component (if applicable):


This problem will become visible when the patch for xenoprof in the xen kernels
is updated to avoid conflicting with the defines in oprofile 0.9.3.
Comment 2 Markus Armbruster 2007-12-04 03:24:02 EST
Upstream discussion on how to support new oprofile versions without breaking old
Comment 4 William Cohen 2007-12-06 18:19:06 EST
Suggested a possible approach to work around this in the following email messages


However, this assumes that xen doesn't work on ppc. There is xen available for
ppc, so this solution won't work in general. However, it might work well enough
for RHEL 5.

Comment 5 Markus Armbruster 2007-12-07 02:21:46 EST
If it weren't for ABI concerns, we'd just change the Xenoprof escape codes not
to conflict.

We care for ABI only after we released a non-tech-preview Xenoprof.  As far as I
know, this is the case only for i386 and x86_64.

We won't support Xen on PPC in RHEL-5.  Therefore, the approach proposed in
comment#4 should work fine for us.

A possible alternative is to stick to the old escape codes for i386 and x86_64,
and use the new ones for everything else:

#if defined(__i386__) || defined(__x86_64__)
#define LAST_CODE			12
#define SPU_PROFILING_CODE              11
#define SPU_CTX_SWITCH_CODE             12
#define LAST_CODE			14

This could be done upstream (I proposed it there), or just in RHEL-5.
Comment 6 Markus Armbruster 2008-01-31 11:44:25 EST
The solution sketched in comment#5 was accepted upstream.  RHEL-5 user space
oprofile picked it up from there (see bug 250852).  Kernel picked up a solution
with the patch for bug 253211[*]; it is functionally equivalent except for
IA-64: there the encoding of escape code DOMAIN_SWITCH_CODE differs.  That one
is used only with Xenoprof, which does not work on IA-64, so the difference
doesn't matter.  It's still somewhat ugly from a maintenance point of view, but
hardly worth cleaning up for 5.2.

[*] linux-2.6-ppc64-cell-support-for-performance-tools-part3.patch
Comment 7 Bill Burns 2008-01-31 11:56:43 EST
Closing based on comment #6.

Note You need to log in before you can comment on or make changes to this bug.