From: Masami Hiramatsu <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Beau Belgrave <beaub@linux.microsoft.com>,
linux-trace-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] user_events: Enable user processes to create and write to trace events
Date: Thu, 14 Oct 2021 21:21:01 +0900 [thread overview]
Message-ID: <20211014212101.d6bddbac7206cba0401c8675@kernel.org> (raw)
In-Reply-To: <20211013114034.13daac32@gandalf.local.home>
On Wed, 13 Oct 2021 11:40:34 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, 14 Oct 2021 00:21:32 +0900
> Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> > > This approach requires an FD returned and either an int for the status
> > > page or the returend FD could expose the ID via another IOCTL being
> > > issued.
> >
> > OK, I would like to suggest you to add events/user-events/*/marker file
> > (which returns that shared file struct backed FD) so that some simple
> > user scripts can also send the events (these may not use ioctl, just
> > write the events.) But this can be done afterwards anyway.
> >
>
> I'd prefer we avoid this. It will break some of the semantics of the events
> directory. One, only "user-events" will have this "marker" file.
Yes, it is only for the user-events.
> Although
> it will be very similar to the "inject" file, but that's only for debugging
> anyway.
Oh, do we already the "inject" file?
> All the files in the events directory is starting to add a bunch of
> overhead, as they are typically copied into the instances. Although, when
> we get the eventfs directory created, maybe that will not be as big of a
> deal. But that still doesn't fix the semantics issue.
Indeed. OK, making "marker" file for each instances may confuse user because
the written event itself must be delivered to any instance but the file
seems to belong to one of them. Please ignore it.
Thank you,
>
> -- Steve
>
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2021-10-14 12:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-05 22:44 [PATCH] user_events: Enable user processes to create and write to trace events Beau Belgrave
2021-10-06 16:28 ` Masami Hiramatsu
2021-10-06 17:56 ` Beau Belgrave
2021-10-07 14:17 ` Masami Hiramatsu
2021-10-07 16:22 ` Beau Belgrave
2021-10-07 23:12 ` Masami Hiramatsu
2021-10-08 0:05 ` Beau Belgrave
2021-10-08 9:22 ` Masami Hiramatsu
2021-10-11 16:25 ` Beau Belgrave
2021-10-13 1:18 ` Steven Rostedt
2021-10-13 16:50 ` Beau Belgrave
2021-10-13 17:11 ` Steven Rostedt
2021-10-13 17:17 ` Beau Belgrave
2021-10-13 17:27 ` Steven Rostedt
2021-10-13 15:21 ` Masami Hiramatsu
2021-10-13 15:40 ` Steven Rostedt
2021-10-14 12:21 ` Masami Hiramatsu [this message]
2021-10-13 16:56 ` Beau Belgrave
2021-10-06 16:54 ` Steven Rostedt
2021-10-06 17:27 ` Beau Belgrave
2021-10-06 17:44 ` Steven Rostedt
2021-10-08 13:11 ` Peter.Enderborg
2021-10-08 16:09 ` Beau Belgrave
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211014212101.d6bddbac7206cba0401c8675@kernel.org \
--to=mhiramat@kernel.org \
--cc=beaub@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).