Hi,
On Thu, 14 Sep 2006, Ingo Molnar wrote:
> also, the other disadvantages i listed very much count too. Static
> tracepoints are fundamentally limited because:
>
> - they can only be added at the source code level
>
> - modifying them requires a reboot which is not practical in a
> production environment
>
> - there can only be a limited set of them, while many problems need
> finegrained tracepoints tailored to the problem at hand
>
> - conditional tracepoints are typically either nonexistent or very
> limited.
>
> for me these are all _independent_ grounds for rejection, as a generic
> kernel infrastructure.
Tracepoints of course need to be managed, but that's true for both dynamic
and static tracepoints. Both have their advantages and disadvantages and
just hammering on the possible problems of static ones (which are not much
of a problem for other people) is highly unfair and not a reason for
rejection. If you don't like them, don't use them, nobody forces you, it's
that simple...
> > You didn't address my main issue at all - kprobes is only available
> > for a few archs...
>
> the kprobes infrastructure, despite being fairly young, is widely
> available: powerpc, i386, x86_64, ia64 and sparc64. The other
> architectures are free to implement them too, there's nothing
> hardware-specific about kprobes and the "porting overhead" is in essence
> a one-time cost - while for static tracepoints the maintainance overhead
> goes on forever and scales linearly with the number of tracepoints
> added.
kprobes are not trivial to implement (especially to reach the level of
perfomance and flexibility of static tracepoints) and until then you deny
their users/developers a useful tool?
I also think you highly exaggerate the maintaince overhead of static
tracepoints, once added they hardly need any maintainance, most of the
time you can just ignore them. Only if the code drastically changes they
need to be adjusted, but at that point this should be the smallest
problem. The kernel is full debug prints, do you seriously suggest to
throw them out because of their "high maintainance"?
bye, Roman
-
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]
