Am 02.05.2014 20:09, schrieb Kamal Mostafa:
On Fri, 2014-05-02 at 13:30 -0400, gregkh wrote:
On Fri, May 02, 2014 at 10:07:33AM -0700, Kamal Mostafa wrote:
Dirk Behme points out that this "Cc: stable" commit breaks the
lttng-modules userspace API when applied to stable kernels. Stable
versions 3.2, 3.8, 3.11, and 3.13 (at least) have all queued it:
af5040da01ef980670b3741b3e10733ee3e33566
blktrace: fix accounting of partially completed requests
On Thu, 2014-05-01 at 10:28 +0200, Dirk Behme wrote:
[...] might break the build of the user space lttng-modules
(lttng-probe-block.c) due the the API change of
trace_block_rq_complete().
[...] On the other hand, looking into the lttng-modules git
http://git.lttng.org/?p=lttng-modules.git;a=commitdiff;h=1c53e689434a6bdd7dc3f54c07bfb72750d1d24c
looks like this is the necessary user space adaption to the kernel
change? So this looks like that lttng-modules expects a KERNEL_VERSION
= (3,15,0) to have this commit?
My inclination is that we probably need to revert/drop "af5040d
blktrace: fix accounting..." from the stable kernels to unbreak the
userspace API.
Then you will run into this issue with 3.15, when it is released.
No, I think "#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,15,0))" in the
lttng-modules commit referenced above guards against that. Apparently,
lttng-modules expects to see the new API in >= 3.15 and the old API in
the stable kernels.
I'm not in the position to judge if it's a lttng or a kernel community
issue ;)
So just for my understanding:
Having
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,15,0))
in lttng-modules commit
http://git.lttng.org/?p=lttng-modules.git;a=commitdiff;h=1c53e689434a6bdd7dc3f54c07bfb72750d1d24c
does mean that we don't have a lttng-modules version which will build
against the -stable kernels (3.2.58, 3,8.13.22 etc) with the back
ported commit [1], atm?
Else, anything like
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,15,0)) ||
(LINUX_VERSION_CODE >= KERNEL_VERSION(3,2,58)) ||
(LINUX_VERSION_CODE >= KERNEL_VERSION(3,8,13,22)) || ...
would be need in above lttng-modules commit?
Thanks
Dirk
[1]
af5040da01ef980670b3741b3e10733ee3e33566
blktrace: fix accounting of partially completed requests
So
might as well be consistant here.
Are tracepoints, and the data within them, being considered as a "user
api" that we can never change / break anymore? As the current
implementation is obviously broken (see the patch for details), why
would it make sense to even keep it around in that state? lttng, by
using that existing api, is reporting incorrect data, wouldn't it make
more sense to fix it up too?
thanks,
greg k-h
Mathieu Desnoyers (author of the lttng-modules patch), can you shed any
more light on this topic?
Thanks,
-Kamal
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html