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: <20090107195456.3247bab5@daedalus.pq.iki.fi>
Date:	Wed, 7 Jan 2009 19:54:56 +0200
From:	Pekka Paalanen <pq@....fi>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Steven Rostedt <rostedt@...dmis.org>, 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 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.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
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