Re: [PATCH -v2] ftrace: Documentation

[Steven Rostedt]

On Fri, 11 Jul 2008, Eric W. Biederman wrote:

> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes:
> >
> > Well that's an interesting question and it has come up before.  There
> > are times when the kernel wants to display a process identifier at
> > least in a printk.  Oopses are one prominent example.
> >
> > Perhaps we do need a way of doing this in a post-pid-namespace-world.
> > Presumably it would be of the form "pidns-identifier:pid", and just
> > plain old "pid" if no pid namespaces are in operation, for some
> > back-compatibility where possible.
> >
> > Eric, any thoughts?
>
> I don't quite know what we are doing here.  Is this a /proc or /sysfs file?

Actually it is a /debug (or /sys/mount/debug if you prefer) file.

>
> After a long series of discussion on semantics what we came up with
> was that the pid namespaces are hierarchical and that a struct pid
> will have a numerical identifier in each pid namespace.  Which means
> that for printing pids in the case of printks especially for oops
> reports we can just go with pid number in the init_pid_ns.  Which is
> the classic system wide pid.
>
> In every other case I know besides printk we are delivering the data to an
> application, and that application is running in a pid namespace
> therefore we really want to figure out the pid namespace and give it the
> information.
>
> For filesystem interfaces (besides proc which provides a natural split)
> the classic answer is to capture namespaces at mount time.  And display
> the data in the filesystem relative to the namespaces we captured.

I'd be interested in knowing who would want namespaces in traces. I've
basically only used tracing to see "what's happening in the kernel here?".
Where I only use the pid to differentiate between the tasks I know are
running.

Hence, tracing is much like printk. Does it really matter with these
outputs. But ftrace is pluggable, pid namespaces may matter in future
plugins.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/