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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Sep 2006 19:55:21 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
	Michel Dagenais <michel.dagenais@...ymtl.ca>
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/