All of lore.kernel.org
 help / color / mirror / Atom feed
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 2/4] tracing/user_events: Introduce multi-format events
Date: Wed, 21 Feb 2024 08:53:37 -0800	[thread overview]
Message-ID: <20240221165337.GA441-beaub@linux.microsoft.com> (raw)
In-Reply-To: <20240221102104.6ab80e5a@gandalf.local.home>

On Wed, Feb 21, 2024 at 10:21:04AM -0500, Steven Rostedt wrote:
> On Wed, 14 Feb 2024 17:50:44 +0000
> Beau Belgrave <beaub@linux.microsoft.com> wrote:
> 
> > Currently user_events supports 1 event with the same name and must have
> > the exact same format when referenced by multiple programs. This opens
> > an opportunity for malicous or poorly thought through programs to
> > create events that others use with different formats. Another scenario
> > is user programs wishing to use the same event name but add more fields
> > later when the software updates. Various versions of a program may be
> > running side-by-side, which is prevented by the current single format
> > requirement.
> > 
> > Add a new register flag (USER_EVENT_REG_MULTI_FORMAT) which indicates
> > the user program wishes to use the same user_event name, but may have
> > several different formats of the event in the future. When this flag is
> 
> "of the event in the future." Does it have to be in the future? Is there
> use case where an application might legitimately want the same event name
> with different formats?
> 

You're right, our use cases are mostly around future facing/compat.
There are valid cases where you just want several different formats with
the same name.

I'll drop the "in the future", so it'll just be "several different
formats".

Thanks,
-Beau

> -- Steve
> 
> > used, create the underlying tracepoint backing the user_event with a
> > unique name per-version of the format. It's important that existing ABI
> > users do not get this logic automatically, even if one of the multi
> > format events matches the format. This ensures existing programs that
> > create events and assume the tracepoint name will match exactly continue
> > to work as expected. Add logic to only check multi-format events with
> > other multi-format events and single-format events to only check
> > single-format events during find.
> > 

  reply	other threads:[~2024-02-21 16:53 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
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 [this message]
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=20240221165337.GA441-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.