> There is no drag on the kernel. The concept that we are working on is
> consistent with your below recommendations. Only place in the kernel an
> efficient tracing infrastructure, keep trace points as patches. [...]
well, this is not the impression i got from the patches posted to lkml ...
> [...] This adds no overhead to kernel, allows your suggested patches to
> use a standard efficient infrastructure, reduces replicated work from
> specific problem to specific problem.
so why not keep the core parts as separate patches as well? If it does
nothing then i dont see why it should get into the kernel proper.
> > my problem with this stuff is conceptual: it introduces a constant drag on
> > the kernel sourcecode, while 99% of development will not want to trace,
>
> If you care about performance you will want to trace. On two previous
> kernels I have worked on I've heard this comment. Once the
> infrastructure was in it was used and appreciated.
(i think you have not read what i have written. I use tracing pretty
frequently, and no, i dont need tracing in the kernel, during development
i can apply patches to kernel trees just fine.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/