linux-kernel - Re: [RFC PATCH 1/3] Unified trace buffer

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: <alpine.DEB.1.10.0809251247010.27920@gandalf.stny.rr.com>
Date:	Thu, 25 Sep 2008 12:53:49 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Ingo Molnar <mingo@...e.hu>, Martin Bligh <mbligh@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Martin Bligh <mbligh@...igh.org>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	prasad@...ux.vnet.ibm.com,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	David Wilder <dwilder@...ibm.com>, hch@....de,
	Tom Zanussi <zanussi@...cast.net>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [RFC PATCH 1/3] Unified trace buffer

On Thu, 25 Sep 2008, Linus Torvalds wrote:
> 
> Not only that, but have you forgotten about FTRACE and -pg? Which means 
> that every single C function calls into tracing code, and that can 
> basically only be disabled on a per-file basis? 

Slight correction. You can annotate the function with "notrace" and 
that function will not be traced. So the "only be disabled on a per-file
basis" statement is false.

> 
> Yeah, it would probably cause some code duplication, but the low-leel 
> trace infrastructure really is special. It can't afford to call other 
> subsystems helper functions, because people want to trace _those_.

Currently my code calls "ring_buffer_time_stamp" to get the time stamp, 
whatever it will be.  Currently it is using sched_clock, but since I have 
it as a wrapper, it shouldn't be too hard to modify later.

I'll also add a "ring_buffer_time_stamp_normalize(ts)" function to be 
called on reading of the trace. This will normalize whatever time stamp 
that we use back to ns for the users. For now it will just return "ts" 
since sched_clock is already normalize.

IOW, for my current work, I don't care what timing we use. Others do, and 
I will try to make the tracing infrastructure let it be easy to change 
what is used. For now, I'm concentrating on the infrastructure itself.

-- Steve

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