linux-kernel - Re: [PATCH v2 0/4] ftrace: important updates

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.0901071302260.17678@gandalf.stny.rr.com>
Date:	Wed, 7 Jan 2009 13:12:28 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Pekka Paalanen <pq@....fi>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Roel Kluin <roel.kluin@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 0/4] ftrace: important updates


On Wed, 7 Jan 2009, Pekka Paalanen wrote:

> On Wed, 7 Jan 2009 10:49:05 +0100
> Ingo Molnar <mingo@...e.hu> wrote:
> 
> > * Steven Rostedt <rostedt@...dmis.org> wrote:
> > 
> > >       ring-buffer: rename debugfs file tracing_on to writing_enabled
> > 
> > writing_enabled is at least as confusing as tracing_on - if not more so.
> > 
> > The user really does not care about all the deeper machinery that happens 
> > in ftrace - the difference between a 'light' disabling of a tracer and a 
> > 'heavy' disabling of a tracer (which means it unregisters itself 
> > completely in essence).
> > 
> > To resolve this, we should probably hide this difference altogether (as i 
> > have suggested to do many months ago, when this first came up), by 
> > removing tracing_enabled.
> > 
> > A tracer can still be fully unregistered: by simply switching the current 
> > tracer to the 'nop' tracer. tracing_on/off remains the lightweight version 
> > that most users are interested in anyway.
> 
> This sounds even better. We should not need tracing_enabled anymore, since
> the buffer size can be changed regardless. tracing_on is more useful to
> mmiotrace than tracing_enabled, too, since mmiotrace does not implement
> the proper pausing behaviour on the tracing_enabled trigger.
> 
> But if Steven wants to keep the "pause" semantics, should there be a
> callback dispatched to the tracer from tracing_on, just like there is
> from tracing_enabled currently? Of course the callback semantics would
> be different and the usual reaction would be to do nothing. It would
> only be meaningful to tracers that update data outside the ring buffer,
> so that they can properly pause.

The tracing_on is implemented by the ring buffer, and disables all ring 
buffers, even those that are not part of ftrace. This file really has no 
concept of a tracer. It simply stops writing to the ring buffer.

Things like the irq latency tracer is will still update its "max time" 
when tracing is off, although the trace output will not be updated.

I could remove tracing_enabled, and move the tracing_on to trace.c,
that just calls the tracing_off of the ring buffer, and then the file will 
be at the higher layer, and have a concept of the current tracer.

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