linux-kernel - Re: ftrace behaviour (was: [PATCH] ftrace: introduce tracing_reset_online

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.0812192148210.29275@gandalf.stny.rr.com>
Date:	Fri, 19 Dec 2008 21:56:44 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Pekka Paalanen <pq@....fi>
cc:	Ingo Molnar <mingo@...e.hu>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Pekka J Enberg <penberg@...helsinki.fi>,
	LKML <linux-kernel@...r.kernel.org>,
	Markus Metzger <markus.t.metzger@...il.com>
Subject: Re: ftrace behaviour (was: [PATCH] ftrace: introduce
 tracing_reset_online_cpus() helper)

On Sat, 20 Dec 2008, Pekka Paalanen wrote:

> > 
> > To implement this at the ftrace level should be a trivial change. I'm just 
> > saying that doing this at the "ring buffer" level might be a bit more 
> > complex. The ring buffer has no idea of ftrace. It should not. It is at 
> > a lower lever than ftrace. Although, I do think some of the protecting 
> > that is done at the tracing level during resize should be moved down into 
> > the ring buffer layer.
> 
> Aah, so you are saying that the buffer_size file (or whatever it was called)
> is part of the ring buffer user API, and not tracing user API?

Nope, the buffer_size is part of the ftrace API. It was just that it 
seemed that Ingo was pushing that the ring buffer API should handle it. I 
may have misunderstood Ingo though. Note, when Ingo and I start going back 
and forth, we sometimes are at the implementation level, and probably will 
confuse the users ;-)

Since the buffer_size is at the ftrace level, it will make it easier to do 
the changes there.

> 
> But the ring buffer is just a buffer, is it meaningful to adjust a ring
> buffer size? I cannot tell tracing to go use a different buffer. And if
> there will be other users of ring buffers, they would probably want to
> have their own control over the buffer size.

Exactly.

> 
> As a user, I want to adjust *the* tracing ring buffer size, not some ring
> buffer size.

Correct, and that is what you are doing.

> 
> Am I making any sense? I'm trying to say that in my opinion, the
> buffer_size file does not belong to the "ring buffer" level. The upper
> levels should decide whether and how it offers buffer resizing.

The "buffer_size" file is part of ftrace, not the ring buffer. You are 
making perfect sense.

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