Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

[Ingo Molnar <mingo@elte.hu>]

* Roman Zippel <zippel@linux-m68k.org> wrote:

> > this tracepoint, under a dynamic tracing concept, can be replaced with:
> > 
> >  int __trace sock_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
>
> A nice example where you make life more difficult for static tracers 
> for no reason, [...]

No, it's simply a clever feature: "halve the impact of static markups".

What you say will be _precisely_ the kind of situations that make me 
very wary of static tracers. Someone does something smart that enables 
us to remove half of the tracepoints from the kernel source code, while 
you will go on and complain: "why do you make the life harder for static 
tracers". You, perhaps inwillingly, are giving the perfect demonstration 
of why static tracepoints are a maintainance problem: once added _they 
can not be removed without breaking static tracers_.

And i see you didnt reply to (and you didnt even quote) the paragraph 
that i believe answers your point:

> > the user of course does not care about kernel internal design and 
> > maintainance issues. Think about the many reasons why STREAMS was 
> > rejected - users wanted that too. And note that users dont want 
> > "static tracers" or any design detail of LTT in particular: what 
> > they want is the _functionality_ of LTT.

The kernel tree is not there to make it easier for inferior approaches. 
How hard is it for the static tracer folks to take a look at dynamic 
tracers and realize that it's the fundamentally better approach, for the 
reasons above and for other reasons, and pick the concept up and 
integrate it with their code? Just like the STREAMS folks had a chance 
to look at the existing TCP/IP implementation in the Linux kernel and 
had the chance to realize that it's the better approach. Yet they 
insisted on just adding a few hooks here and there, to "make the life 
easier for STREAMS".

	Ingo