Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 3 May 2021 16:55:22 -0400
From:   Steven Rostedt <rostedt@goodmis.org>
To:     ebiederm@xmission.com (Eric W. Biederman)
Cc:     <Peter.Enderborg@sony.com>, <mathieu.desnoyers@efficios.com>,
        <linux-kernel@vger.kernel.org>, <mingo@redhat.com>,
        <akpm@linux-foundation.org>, <peterz@infradead.org>,
        <ast@kernel.org>, <christian.brauner@ubuntu.com>,
        <dave@stgolabs.net>, <walken@google.com>, <jannh@google.com>,
        <christophe.leroy@c-s.fr>, <minchan@kernel.org>
Subject: Re: [PATCH 1/2] tracing: Add a trace for task_exit
Message-ID: <20210503165522.6f1f2fc3@gandalf.local.home>
In-Reply-To: <m1a6pbk5d3.fsf@fess.ebiederm.org>
References: <20210430142223.25500-1-peter.enderborg@sony.com>
        <20210430142223.25500-2-peter.enderborg@sony.com>
        <m14kfnzmsp.fsf@fess.ebiederm.org>
        <4bb24db4-f720-f5e7-9054-36bdeaee1d79@sony.com>
        <20210501091104.418765bd@oasis.local.home>
        <1214833117.22933.1620049830326.JavaMail.zimbra@efficios.com>
        <769a00d2-a76d-62d2-aa56-5a107dfdc53d@sony.com>
        <m1sg33lqyo.fsf@fess.ebiederm.org>
        <663fc7fa-e7fc-7d63-9de8-91b5f6fe4f06@sony.com>
        <m1a6pbk5d3.fsf@fess.ebiederm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Mon, 03 May 2021 14:02:48 -0500
ebiederm@xmission.com (Eric W. Biederman) wrote:

> > However current traces is template based, and I assume it wont be
> > popular to add new fields to the template, and exit reasons is not
> > right for the other template use cases.

trace events can always add fields, it's removing them that can cause
problems (but even then, it's not that bad). The new libtracefs and
libtraceevent make it trivial for tools to get the fields from trace events
when needed.

> >
> > I still see a "new" task moving it to do_exit make trace name more
> > correct?  Or is trace_task_do_exit better?  

It is also trivial with the libraries to write a tool that can put together
everything you want. We even are working on python bindings to connect to
these libraries where you could write a python script to do this.

There is no need for a new tracepoint, especially if it makes it harder to
improve the implementation of what is being traced.

> 
> I really can't say, as I don't know much of anything about the tracing
> infrastructure.  I would assume in most cases with a tracepoint in place
> other kinds of tracing (like bpf programs) could come into play and read
> out pieces of information that are not commonly wanted.
> 
> All I really know something about is the exit code path, as I keep
> slowly trying to clean it up.  I plan on ignoring any tracepoint that
> makes that gets in the way.

As you should.

-- Steve