Re: [PATCH -v2] ftrace: Documentation

[Eric W. Biederman]

Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes:

> On Fri, 11 Jul 2008 16:59:53 -0400 (EDT) Steven Rostedt <rostedt@xxxxxxxxxxx>

>> > > +
>> > > +Here's an example of the output format of the file "trace"
>> > > +
>> > > +                             --------
>> > > +# tracer: ftrace
>> > > +#
>> > > +#           TASK-PID   CPU#    TIMESTAMP  FUNCTION
>> > > +#              | |      |          |         |
>> > > +            bash-4251  [01] 10152.583854: path_put <-path_walk
>> > > +            bash-4251  [01] 10152.583855: dput <-path_put
>> > > +            bash-4251  [01] 10152.583855: _atomic_dec_and_lock <-dput
>> > > +                             --------
>> >
>> > pids are no longer unique system-wide, and any part of the kernel ABI which
>> > exports them to userspace is, basically, broken.  Oh well.
>> 
>> What should be used instead?  Of course we're not using a kernel ABI, we
>> are using an API (text based ;-) But more on that later.
>
> 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?

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.

Eric




--
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/