Re: [PATCH -v2] ftrace: Documentation

[ebiederm@xmission.com (Eric W. Biederman)]

Steven Rostedt <rostedt@goodmis.org> writes:

> On Mon, 14 Jul 2008, Eric W. Biederman wrote:
>
>>
>> Steven Rostedt <rostedt@goodmis.org> writes:
>>
>> > Actually it is a /debug (or /sys/mount/debug if you prefer) file.
>>
>> Got it.  I haven't ever actually seen anyone use debugfs.
>>
>> > 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.
>
> Bare with me, I'm new to the namespace concept of pids.

Sure.  Just bare with me as I am new to the concept of ftrace.

>> So it would not be hard to capture the pid namespace in mount or
>> even look at current to get it (although the last is a little odd).
>
>>From userspace or from with the kernel (doing the trace)
>
>>
>> I'm not at all certain if it makes sense.  If this is something
>> an ordinary user could use then we definitely want to do something.
>>
>> Is tracing possible without inserting kernel modules?
>
> The tracer is built into the kernel (no module needed).

Ok.  So this is something simpler to use then SystemTap.  Yeah.

It sounds like it is reasonable or at least semi reasonable to use
this as an unprivileged user.

The easiest model to think of this in is a chroot that does pids as
well as the filesystem.  In which case if you are inside one and
you use the tracer.  You want pids that are meaningful in your
subset of userspace, and not the global ones.

Eric