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]
Message-ID: <20060917221328.GA8791@elte.hu>
Date:	Mon, 18 Sep 2006 00:13:28 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	Thomas Gleixner <tglx@...utronix.de>, karim@...rsys.com,
	Andrew Morton <akpm@...l.org>,
	Paul Mundt <lethal@...ux-sh.org>, Jes Sorensen <jes@....com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.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:

> > I am really sorry that you were able to misunderstand and 
> > misrepresent such a simple sentence.
> 
> Considering the context, which is not exactly full of support for 
> static tracer, I think my understanding was and still is quite 
> correct.

this thought of you is still false. Nick said:

 ' I think Ingo said that some "static tracepoints" (eg. annotation) 
   could be acceptable. '

to which you replied:

  ' No, he made it rather clear, that as far as possible he only wants 
    dynamic annotations (e.g. via function attributes). '

That "No" word at the beginning of your sentence, by its plain meaning, 
falsely questions Nick's correct interpretation of what I said. I ask 
you to retract or correct this false statement.

Nick is of course correct: i said before that some static markups could 
be acceptable. In fact, i even outlined a possible API for such static 
markups in 20060914231956.GB29229@...e.hu. Would I want to reduce the 
number of such static markups: of course, not wanting to reduce the 
number of subsystem-functionality unrelated source code lines would be 
foolish.

> > this makes it clear that i disagree with adding static markups for 
> > static tracers - but i of course still agree with static markups for 
> > _dynamic tracers_. The markups would be totally unusable for static 
> > tracers because there is no guarantee for the existence of static 
> > markups _everywhere_: the static markups would come and go, as per 
> > the "tracepoint maintainance model". Do you understand that or 
> > should i explain it in more detail?
> 
> Well, I rather just wait for the real patch, where you can show your 
> support for all possible users.

this answer of yours does not rectify the false statement you did.

Your sentence also introduces a new misrepresentation of my intentions: 
my intention with partial static markups (which intention i've written 
to you about before, so it was known to you when you wrote this 
stentence) is not to support "all possible users", but to support 
dynamic tracers. Static tracers cannot use static markups that go away 
into dynamic tracing scripts.

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ