On 3/26/18 8:47 AM, Steven Rostedt wrote:

On Mon, 26 Mar 2018 17:32:02 +0200
Daniel Borkmann [off-list ref] wrote:

quoted

On 03/26/2018 05:04 PM, Steven Rostedt wrote:

quoted

On Mon, 26 Mar 2018 10:28:03 +0200
Daniel Borkmann [off-list ref] wrote:

quoted

quoted

tracepoint    base  kprobe+bpf tracepoint+bpf raw_tracepoint+bpf
task_rename   1.1M   769K        947K            1.0M
urandom_read  789K   697K        750K            755K

Applied to bpf-next, thanks Alexei!

Please wait till you have the proper acks. Some of this affects
tracing.

Ok, I thought time up to v5 was long enough. Anyway, in case there are
objections I can still toss out the series from bpf-next tree worst case
should e.g. follow-up fixups not be appropriate.

Yeah, I've been traveling a bit which slowed down my review process
(trying to catch up).

v1 of this set was posted Feb 28.
imo one month is not an acceptable delay for maintainer to review
the patches. You really need to consider group maintainership as
we do with Daniel for bpf tree.

My main concern is with patch 6, as there are
external users of those functions. Although, we generally don't cater
to out of tree code, we play nice with LTTng, and I don't want to break
it.

out-of-tree module is out of tree. I'm beyond surprised that you
propose to keep for_each_kernel_tracepoint() as-is with zero in-tree
users in order to keep lttng working.

I also should probably pull in the patches and run them through my
tests to make sure they don't have any other side effects.

so let me rephrase.
You're saying that a change to a function with zero in-tree users
can somehow break your tests?
How is that possible?
Does it mean you also have some out-of-tree modules that will break?
and that _is_ the real reason for objection?