All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Steven Rostedt <srostedt@redhat.com>
Subject: Re: [PATCH 1/7] tracing: give easy way to clear trace buffer
Date: Thu, 19 Mar 2009 21:26:32 +0100	[thread overview]
Message-ID: <20090319202631.GA5935@nowhere> (raw)
In-Reply-To: <20090319200159.932486704@goodmis.org>

On Thu, Mar 19, 2009 at 04:01:23PM -0400, Steven Rostedt wrote:
> From: Steven Rostedt <srostedt@redhat.com>
> 
> There is currently no easy way to clear the trace buffer. Currently
> the only way is to change the current tracer.
> 
> This patch lets the user clear the trace buffer by simply writing
> into the trace files.
> 
>  echo > /debug/tracing/trace
> 
> or to clear a single cpu (i.e. for CPU 1):
> 
>  echo > /debug/tracing/per_cpu/cpu1/trace
> 
> Requested-by: Ingo Molnar <mingo@elte.hu>
> Signed-off-by: Steven Rostedt <srostedt@redhat.com>
> ---
>  kernel/trace/trace.c |   41 +++++++++++++++++++++++++++++++++--------
>  1 files changed, 33 insertions(+), 8 deletions(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index a2d13e8..8d981ab 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -1941,9 +1941,14 @@ int tracing_open_generic(struct inode *inode, struct file *filp)
>  static int tracing_release(struct inode *inode, struct file *file)
>  {
>  	struct seq_file *m = (struct seq_file *)file->private_data;
> -	struct trace_iterator *iter = m->private;
> +	struct trace_iterator *iter;
>  	int cpu;
>  
> +	if (!(file->f_mode & FMODE_READ))
> +		return 0;
> +
> +	iter = m->private;
> +
>  	mutex_lock(&trace_types_lock);
>  	for_each_tracing_cpu(cpu) {
>  		if (iter->buffer_iter[cpu])
> @@ -1969,12 +1974,24 @@ static int tracing_open(struct inode *inode, struct file *file)
>  	struct trace_iterator *iter;
>  	int ret = 0;
>  
> -	iter = __tracing_open(inode, file);
> -	if (IS_ERR(iter))
> -		ret = PTR_ERR(iter);
> -	else if (trace_flags & TRACE_ITER_LATENCY_FMT)
> -		iter->iter_flags |= TRACE_FILE_LAT_FMT;
> +	/* If this file was open for write, then erase contents */
> +	if ((file->f_mode & FMODE_WRITE) &&
> +	    !(file->f_flags & O_APPEND)) {
> +		long cpu = (long) inode->i_private;
> +
> +		if (cpu == TRACE_PIPE_ALL_CPU)
> +			tracing_reset_online_cpus(&global_trace);
> +		else
> +			tracing_reset(&global_trace, cpu);
> +	}
>  
> +	if (file->f_mode & FMODE_READ) {
> +		iter = __tracing_open(inode, file);
> +		if (IS_ERR(iter))
> +			ret = PTR_ERR(iter);
> +		else if (trace_flags & TRACE_ITER_LATENCY_FMT)
> +			iter->iter_flags |= TRACE_FILE_LAT_FMT;
> +	}
>  	return ret;
>  }
>  
> @@ -2049,9 +2066,17 @@ static int show_traces_open(struct inode *inode, struct file *file)
>  	return ret;
>  }
>  
> +static ssize_t
> +tracing_write_stub(struct file *filp, const char __user *ubuf,
> +		   size_t count, loff_t *ppos)
> +{
> +	return count;
> +}


Is this one necessary?
I guess debugfs or vfs layers already provide a stub for write. No?

Anyway, that's a small detail for this good patch idea.

Frederic.


>  static const struct file_operations tracing_fops = {
>  	.open		= tracing_open,
>  	.read		= seq_read,
> +	.write		= tracing_write_stub,
>  	.llseek		= seq_lseek,
>  	.release	= tracing_release,
>  };
> @@ -3576,7 +3601,7 @@ static void tracing_init_debugfs_percpu(long cpu)
>  		pr_warning("Could not create debugfs 'trace_pipe' entry\n");
>  
>  	/* per cpu trace */
> -	entry = debugfs_create_file("trace", 0444, d_cpu,
> +	entry = debugfs_create_file("trace", 0644, d_cpu,
>  				(void *) cpu, &tracing_fops);
>  	if (!entry)
>  		pr_warning("Could not create debugfs 'trace' entry\n");
> @@ -3890,7 +3915,7 @@ static __init int tracer_init_debugfs(void)
>  	if (!entry)
>  		pr_warning("Could not create debugfs 'tracing_cpumask' entry\n");
>  
> -	entry = debugfs_create_file("trace", 0444, d_tracer,
> +	entry = debugfs_create_file("trace", 0644, d_tracer,
>  				 (void *) TRACE_PIPE_ALL_CPU, &tracing_fops);
>  	if (!entry)
>  		pr_warning("Could not create debugfs 'trace' entry\n");
> -- 
> 1.6.2
> 
> -- 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  reply	other threads:[~2009-03-19 20:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-19 20:01 [PATCH 0/7] [GIT PULL] tip/tracing/ftrace Steven Rostedt
2009-03-19 20:01 ` [PATCH 1/7] tracing: give easy way to clear trace buffer Steven Rostedt
2009-03-19 20:26   ` Frederic Weisbecker [this message]
2009-03-19 23:52     ` Steven Rostedt
2009-03-19 20:01 ` [PATCH 2/7] ftrace: protect running nmi (V3) Steven Rostedt
2009-03-19 20:01 ` [PATCH 3/7] function-graph: consolidate prologues for output Steven Rostedt
2009-03-19 20:01 ` [PATCH 4/7] tracing: make print_(b)printk_msg_only global Steven Rostedt
2009-03-19 20:01 ` [PATCH 5/7] function-graph: calculate function depth within function graph tracer Steven Rostedt
2009-03-19 20:01 ` [PATCH 6/7] tracing: remove recording function depth from trace_printk Steven Rostedt
2009-03-19 20:01 ` [PATCH 7/7] function-graph: show binary events as comments Steven Rostedt
2009-03-19 20:52   ` Frederic Weisbecker
2009-03-20  9:15 ` [PATCH 0/7] [GIT PULL] tip/tracing/ftrace Ingo Molnar
2009-03-20 10:14   ` Ingo Molnar
2009-03-20 13:56     ` Frederic Weisbecker
2009-03-20 16:02     ` Frederic Weisbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090319202631.GA5935@nowhere \
    --to=fweisbec@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=srostedt@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.