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

Ingo Molnar
2006-09-16T08:29:23Z

* 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