linux-kernel - Re: [RFC] Unified Ring Buffer (Next Generation)

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:	Wed, 19 May 2010 15:05:04 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Christoph Hellwig <hch@....de>, Li Zefan <lizf@...fujitsu.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Johannes Berg <johannes.berg@...el.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Tom Zanussi <tzanussi@...il.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [RFC] Unified Ring Buffer (Next Generation)

* Steven Rostedt (rostedt@...dmis.org) wrote:
[...]
> Unfortunately, we are now back with more than one ring buffer in the
> kernel. What's worse, neither of them can perform all the features
> needed. This is putting a bit of stress on the users of these tools, not
> to mention the stress on the developers as well.
[...]
> This email is about finding a solution to the problem. If we can once
> again create a generic ring buffer that handles all requirements, then
> we can also merge the functionality of ftrace into perf, and lower the
> duplication of code within the kernel.
> 
> 
> This time around, I'm asking Mathieu Desnoyers to come to the plate, and
> see if he can handle the task.
> 
> I'm hoping that this email will start a thread that gets everyone into
> agreement and produces something that will make everyone happy.

I also hope this will get us to a state of concensus.

For the records: I'm willing to handle that task. I plan to use the

  git://git.kernel.org/pub/scm/linux/kernel/git/compudj/linux-2.6-ringbuffer.git

git tree to publish my work (and to submit occasional rounds of patches to LKML
too)

The current state of that tree is that it includes only the bare-bone ring
buffer core, without the filesystem operations, only for per-cpu buffers, and
still needs a bit of cleanup. It's currently in kernel/trace/, but, as we
discussed, it's probably better if I move it to kernel/ringbuffer/, because it
does not have to be tied specifically to tracers. I'm doing it with tracing in
mind, but it could be reused as generic ring buffer in the future.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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/