[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081126100450.24b99063.akpm@linux-foundation.org>
Date: Wed, 26 Nov 2008 10:04:50 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Frederic Weisbecker <fweisbec@...il.com>,
containers@...ts.osdl.org,
Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
"Serge E. Hallyn" <serue@...ibm.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 4/5] ftrace: add thread comm to function graph tracer
On Wed, 26 Nov 2008 11:48:44 -0500 (EST) Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Tue, 25 Nov 2008, Andrew Morton wrote:
>
> > On Wed, 26 Nov 2008 00:16:26 -0500 Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > > From: Steven Rostedt <rostedt@...dmis.org>
> > >
> > > Impact: enhancement to function graph tracer
> > >
> > > Export the trace_find_cmdline so the function graph tracer can
> > > use it to print the comms of the threads.
> > >
> > > -static char *trace_find_cmdline(int pid)
> > > +char *trace_find_cmdline(int pid)
> > >
> > > ...
> > >
> > > static int verif_pid(struct trace_seq *s, pid_t pid)
> > > {
> > > + char *comm;
> > > +
> > > if (last_pid != -1 && last_pid == pid)
> > > return 1;
> > >
> > > last_pid = pid;
> > > - return trace_seq_printf(s, "\n------------8<---------- thread %d"
> > > + comm = trace_find_cmdline(pid);
> > > +
> > > + return trace_seq_printf(s, "\n------------8<---------- thread %s-%d"
> > > " ------------8<----------\n\n",
> > > - pid);
> > > + comm, pid);
> > > }
> >
> > This code gets its int's and pid_t's all mixed up. It's a bit cosmetic, but
> > nice to get it right for readability's sake.
>
> Hmm, I think I would like to keep all pids as ints. Perhaps because we do
> not have namespaces here ;-)
>
> I'm totally confused by what to do. I'll have to think about it.
Well. Any variable which contains a process ID should have type pid_t.
It gets more complicated in places where these values are passed to and
from userspace (including via printk!). It would be defensive (but
unnecessary) to cast the pid_t's to and from known-size types at the
kernel boundaries.
--
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