* Roman Zippel <[email protected]> wrote:
> > to both points i (and others) already replied in great detail -
> > please follow up on them. (I can quote message-IDs if you cannot
> > find them.)
>
> What you basically tell me is (rephrased to make it more clear):
> Implement kprobes support or fuck off! [...]
What i am saying (again and again) is: "the other option you suggest is
not acceptable to me because a better solution exists" [for the many
reasons outlined before]. Think about the STREAMS example: there too
_that_ particular approach was rejected, because a better solution
existed. (although it was a _much_ larger body of code that was
rejected)
I'm not "forcing" kprobes on you: you can invent whatever other approach
that solves the problems i and others raised, or you can have your own
separate patchset - this is standard kernel acceptance procedure.
Granted, kprobes is an existing solution with extensive existing
infrastructure, so it's IMO the easiest solution technically, but you
are certainly not 'forced' to do it. You want the feature on your
architecture _without_ kprobes, solve the problems.
> [...] You make it very clear, that you're unwilling to support static
> tracers even to point to make _any_ static trace support impossible.
> It's impossible to discuss this with you, because you're absolutely
> unwilling to make any concessions. [...]
Because we either accept the concept of static tracing or not -
unfortunately there's no meaningful middle ground. I'd love it if there
was some meaningful middle-ground, because then we'd not have this
lengthy discussion at all. But sometimes such situations do happen. Same
was true for STREAMS: the only choice was to either it was accepted or
it was rejected. One cannot get a "little bit pregnant".
The "add some static markups" suggestion is IMO just tactical pretense:
static tracing will only be fully functional once it grows a
comprehensive set of static tracepoints, so once we accept a "little
bit" of static tracing where all the tools are built around a full set
of tracepoints, we've created an expectance to have all of it.
Hence my suggestion: forget static tracing for the LTT engine and
concentrate on dynamic tracepoints with _static markups_. Do you realize
that dynamic tracers can insert _function calls_ into static markups,
today? [and i'm not talking about djprobes here but current existing
SystemTap behavior.]
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
