[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090916081556.GA2457@jolsa.lab.eng.brq.redhat.com>
Date: Wed, 16 Sep 2009 10:15:56 +0200
From: Jiri Olsa <jolsa@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Li Zefan <lizf@...fujitsu.com>, mingo@...e.hu,
linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2] tracing - support multiple pids in set_pid_ftrace
file
On Tue, Sep 15, 2009 at 09:33:33PM -0400, Steven Rostedt wrote:
> On Wed, 2009-09-16 at 09:00 +0800, Li Zefan wrote:
> > jolsa@...hat.com wrote:
> > > Adding the possibility to set more than 1 pid in the set_pid_ftrace file,
> > > thus allowing to trace more than 1 independent processes.
> > >
> > > Usage:
> > >
> > > sh-4.0# echo 284 > ./set_ftrace_pid
> > > sh-4.0# cat ./set_ftrace_pid
> > > 284
> > > sh-4.0# echo 1 >> ./set_ftrace_pid
> > > sh-4.0# echo 0 >> ./set_ftrace_pid
> > > sh-4.0# cat ./set_ftrace_pid
> > > swapper tasks
> > > 1
> > > 284
> > > sh-4.0# echo 4 > ./set_ftrace_pid
> > > sh-4.0# cat ./set_ftrace_pid
> > > 4
> > > sh-4.0# echo > ./set_ftrace_pid
> > > sh-4.0# cat ./set_ftrace_pid
> > > no pid
> > > sh-4.0#
> > >
> > >
> > > wbr,
> > > jirka
> > >
> > > Signed-off-by: Jiri Olsa <jolsa@...hat.com>
> >
> > Looks good.
> >
> > Reviewed-by: Li Zefan <lizf@...fujitsu.com>
>
> Thanks!
>
> >
> > a few nitpicks.
> >
> > > /* set when tracing only a pid */
> >
> > This comment should be removed too.
>
> Yeah, it goes with the deleted pointer below.
>
> >
> > > -struct pid *ftrace_pid_trace;
> > > static struct pid * const ftrace_swapper_pid = &init_struct_pid;
> > >
> > ...
> > > +static int ftrace_pid_add(int p)
> > > +{
> > > + struct pid *pid;
> > > + struct ftrace_pid *fpid;
> > > + int ret = -EINVAL;
> > > +
> > > + mutex_lock(&ftrace_lock);
> > > +
> > > + if (!p)
> > > + pid = ftrace_swapper_pid;
> > > + else
> > > + pid = find_get_pid(p);
> > > +
> > > + if (!pid)
> > > + goto out;
> > > +
> > > + list_for_each_entry(fpid, &ftrace_pids, list)
> > > + if (fpid->pid == pid)
> > > + goto out_put;
> >
> > rather than returning EINVAL, return EEXIST or just return 0?
>
> I agree, return 0, if it already exists, there's no harm in it returning
> success.
>
> -- Steve
thanks, I sent out v3
wbr,
jirka
--
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