From: Beau Belgrave <beaub@linux.microsoft.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: mhiramat@kernel.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
mathieu.desnoyers@efficios.com
Subject: Re: [PATCH v3 1/4] tracing/user_events: Prepare find/delete for same name events
Date: Wed, 21 Feb 2024 09:04:15 -0800 [thread overview]
Message-ID: <20240221170415.GC441-beaub@linux.microsoft.com> (raw)
In-Reply-To: <20240221101721.4e81e9e5@gandalf.local.home>
On Wed, Feb 21, 2024 at 10:17:21AM -0500, Steven Rostedt wrote:
> On Wed, 14 Feb 2024 17:50:43 +0000
> Beau Belgrave <beaub@linux.microsoft.com> wrote:
>
> So the patches look good, but since I gave you some updates, I'm now going
> to go though "nits". Like grammar and such ;-)
>
Sure thing.
> > The current code for finding and deleting events assumes that there will
> > never be cases when user_events are registered with the same name, but
> > different formats. In the future this scenario will exist to ensure
>
> > user programs can be updated or modify their events and run different
> > versions of their programs side-by-side without being blocked.
>
> Can you change the last sentence above. I read it three times and it's
> still awkward to understand it. Particularly, the "user programs can be
> updated or modify their events". That just doesn't want to compute.
>
Yeah, I'll clean this up.
> >
> > This change does not yet allow for multi-format events. If user_events
> > are registered with the same name but different arguments the programs
> > see the same return values as before. This change simply makes it
> > possible to easily accomodate for this in future changes.
>
> I think you can drop the "in future changes" part.
>
Agreed.
> >
> > Update find_user_event() to take in argument parameters and register
> > flags to accomodate future multi-format event scenarios. Have find
> > validate argument matching and return error pointers to cover address
> > in use cases, or allocation errors. Update callers to handle error
>
> "to cover address in use cases" ?
Yeah, if the ABI is using a single-format event and it's already in use,
we return -EADDRINUSE. It does not happen in multi-format event cases,
since that is allowed.
I'll try to clarify this a bit.
>
> > pointer logic.
> >
> > Move delete_user_event() to use hash walking directly now that find has
> > changed. Delete all events found that match the register name, stop
>
> "now that find has changed" ? You mean the "find function"?
>
Yeah, I'll just use the function name here, find_user_event().
> > if an error occurs and report back to the user.
> >
> > Update user_fields_match() to cover list_empty() scenarios instead of
> > each callsite doing it now that find_user_event() uses it directly.
>
> The above is a bit of a run-on sentence.
>
I'll clean it up a bit.
Thanks,
-Beau
> -- Steve
>
> >
> > Signed-off-by: Beau Belgrave <beaub@linux.microsoft.com>
> > ---
next prev parent reply other threads:[~2024-02-21 17:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-14 17:50 [PATCH v3 0/4] tracing/user_events: Introduce multi-format events Beau Belgrave
2024-02-14 17:50 ` [PATCH v3 1/4] tracing/user_events: Prepare find/delete for same name events Beau Belgrave
2024-02-21 15:17 ` Steven Rostedt
2024-02-21 17:04 ` Beau Belgrave [this message]
2024-02-14 17:50 ` [PATCH v3 2/4] tracing/user_events: Introduce multi-format events Beau Belgrave
2024-02-21 15:08 ` Steven Rostedt
2024-02-21 16:56 ` Beau Belgrave
2024-02-21 15:21 ` Steven Rostedt
2024-02-21 16:53 ` Beau Belgrave
2024-02-14 17:50 ` [PATCH v3 3/4] selftests/user_events: Test " Beau Belgrave
2024-02-14 17:50 ` [PATCH v3 4/4] tracing/user_events: Document multi-format flag 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=20240221170415.GC441-beaub@linux.microsoft.com \
--to=beaub@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.