On 9/11/12 9:11 AM, Robert Richter wrote:
On 11.09.12 08:32:55, David Ahern wrote:
My guess would be /usr/include/bits/errno.h:
/* Linux has no ENOTSUP error code. */
# define ENOTSUP EOPNOTSUPP
Ok, so ENOTSUP is actually the same as EOPNOTSUPP. Since the syscall
returns a EOPNOTSUPP, I prefer this when checking perf_event_open()
return codes. ENOTSUP is not used in the kernel. Was there a reason
for choosing ENOTSUP?
poor memory? laziness? a habit I was not aware I had acquired with using
ENOTSUP? I mentioned in a prior response I would change it to EOPNOTSUPP
to be consistent with the 2nd patch -- what the kernel is returning.
If you run this bare-metal on older machines which do not support pebs
or ibs, the syscall returns EOPNOTSUPP. You can trigger the same
behaviour on newer systems with:
# perf record -e cycles:ppp -c 2097120 -R -a sleep 1
Error: sys_perf_event_open() syscall returned with 95 (Operation not
supported). /bin/dmesg may provide additional information.
...
It should work in this case too.
The commit message was a copy and paste from the failure of both :p in a
VM (PEBS is not supported in a VM). I also ran the bare metal case with
:pG which per the second patch in this series generates the not
supported message.
Since the error codes are the same, your code should work also on
bare-metal. Can you test on a host using :ppp? This should trigger the
same error message as in a vm.
As expected:
$ perf record -e cycles:ppp -a
Error:
'precise' request not supported. Try removing 'p' modifier
Resending patchset in a few minutes.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
