Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sun, 1 Mar 2020 13:18:16 -0500
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Chris Wilson <chris@chris-wilson.co.uk>
Cc:     intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] trace: Export anonymous tracing
Message-ID: <20200301131816.277dd398@oasis.local.home>
In-Reply-To: <20200301155248.4132645-1-chris@chris-wilson.co.uk>
References: <20200301155248.4132645-1-chris@chris-wilson.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun,  1 Mar 2020 15:52:47 +0000
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> To facilitate construction of per-client event ringbuffers, in
> particular for a per-client debug and error report log, it would be
> extremely useful to create an anonymous file that can be handed to
> userspace so that it can see its and only its events. trace already
> provides a means of encapsulating the trace ringbuffer into a struct
> file that can be opened via the tracefs, and so with a couple of minor
> tweaks can provide the same access via an anonymous inode.

I'm curious to why we need it to be anonymous. Why not allow them to be
visible from the tracing directory. This could allow for easier
debugging. Note, the trace instances have ref counters thus they can't
be removed if something has a reference to it.

Also, all the global functions require kernel doc comments to explain
how they work and what they are for.

-- Steve


> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
> ---
>  include/linux/trace.h |   4 ++
>  kernel/trace/trace.c  | 142 ++++++++++++++++++++++++++++++------------
>  2 files changed, 105 insertions(+), 41 deletions(-)
>