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 22:24:52 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roman Zippel <zippel@...ux-m68k.org>
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

* Roman Zippel <zippel@...ux-m68k.org> 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.
> 
> Sorry, but I fail to see the point you're trying to make (beside your 
> personal preferences), none of this is a unsolvable problem, which 
> would prevent making good use of static tracepoints.

those are technical arguments - i'm not sure how you can understand them 
to be "personal preferences". The only personal preference i have is 
that in the end a technically most superior solution should be merged. 
(be that one project or the other, or a hybrid of the two) The analysis 
of which one is a better solution depends on pros and cons - exactly 
like the ones listed above. If they are solvable problems then please 
let me know how you would solve them and when you (or others) would 
solve them, preferably before merging the code. Right now they are 
pretty heavy cons as far as LTT goes, so obviously they have a primary 
impact on the topic at hand (whic is whether to merge LTT or not).

	Ingo
-
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/