* Frank Ch. Eigler <[email protected]> wrote:
> [...] It would be much better if we were able to sketch out plausible
> designs for static instrumentation and similar dynamic probes, and
> carry out gedanken experiments aobut how they would need to adopt to
> realistic examples of code drift. It is not the case that all
> "maintenance" is alike.
see my previous mail - hopefully that explains my position even clearer.
A number of people have expressed doubts about the all-static model (i'm
amongst them) - and that's all based on actual experience. So there's no
need for Gedanken-experiments, because we've got real-life experiments
:-) A number of people also have expressed that they think an all-static
markup model is the right one - and that's based on experience as well.
Just looking at the opinions objectively and excluding my opinion i'd
say that the most likely model will thus be a _hybrid_ one: some
markups will be static, some will be dynamic.
Whether a tracepoint will be static or dynamic will depend on the 'flux
of changes' in the tracing code and of the code they trace. If tracing
code has a high flux, or the traced code has a high flux, then the
lowest maintainance overhead is to have a dynamic tracepoint. If _both_
the tracing code and the traced code has low flux of changes, then the
lowest maintainance overhead will be a static markup.
Put differently: dynamic markups will turn into static markups if the
code that they handle "cools down". Static markups will turn into
dynamic markups if the code where they reside in gets "too hot" or if
the markups themselves are "too hot".
But one thing is sure: with a static tracer model accepted into the
kernel we are forced to have a comprehensive, always-maintained, full
set of static markups in the tree, for a long time. Dynamic tracers will
still be around, but we wont be able to fully benefit from the more
flexible tracepoint maintainance models they allow, because we'll always
have to carry around the static markups, for the sake of static tracers.
There will likely be periodic friction about how many static markups
there should be in the source: subsystem maintainers will want them out,
static-trace-users will want them in. If a crutial static markup is
removed or damaged then the kernel will regress materially.
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]
