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, mathieu.desnoyers@efficios.com,
	linux-trace-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org
Subject: Re: [PATCH v2 6/7] tracing/user_events: Use bits vs bytes for enabled status page data
Date: Tue, 26 Jul 2022 19:01:47 -0700	[thread overview]
Message-ID: <20220727020147.GA1705@kbox> (raw)
In-Reply-To: <20220726201412.7fbd3b1f@rorschach.local.home>

On Tue, Jul 26, 2022 at 08:14:12PM -0400, Steven Rostedt wrote:
> On Tue, 26 Jul 2022 17:02:49 -0700
> Beau Belgrave <beaub@linux.microsoft.com> wrote:
> 
> > > >  /* Limit how long of an event name plus args within the subsystem. */
> > > >  #define MAX_EVENT_DESC 512
> > > >  #define EVENT_NAME(user_event) ((user_event)->tracepoint.name)
> > > >  #define MAX_FIELD_ARRAY_SIZE 1024
> > > >  
> > > > +#define STATUS_BYTE(bit) ((bit) >> 3)
> > > > +#define STATUS_MASK(bit) (1 << ((bit) & 7))
> > > > +
> > > > +/* Internal bits to keep track of connected probes */
> > > > +#define EVENT_STATUS_FTRACE (1 << 0)
> > > > +#define EVENT_STATUS_PERF (1 << 1)
> > > > +#define EVENT_STATUS_OTHER (1 << 7)  
> > > 
> > > Did you mean to shift STATUS_OTHER by 7?
> > >   
> > 
> > Yes, it should be the value 128.
> > 
> > > Is EVENT_STATUS_OTHER suppose to be one of the flags within the 3 bits of
> > > the 7 in STATUS_MASK?
> > >   
> > 
> > My thought was that STATUS_OTHER would stay on the highest bit.
> > Then when we have other systems they would slot into (1 << 2), etc.
> > 
> > This may not be as important now since the byte is never given back to
> > the user and is only used when printing out status via the
> > user_events_status file in text form.
> 
> So, it is confusing because of STATUS_MASK() is bits 0,1,2 and we are
> only using bits 0 and 1, with a OTHER bit at bit 7. And it would be
> good to use the BIT() macro.
> 

Ah, I see the confusion. Sorry.  

EVENT_STATUS_* are internal bits that aren't used with STATUS_MASK or
STATUS_BYTE. It's only used to set and check the user event status byte
for checking if anything is attached and outputting which probe is
connected within the kernel side.

STATUS_BYTE and STATUS_MASK take a bit in a bitmap and figure out which
byte in the status mapping should be used and which bit in that byte
should be set/reset (mask) when it's enabled/disabled via a probe. Both
the user and kernel need to align on this logic.

IE: Bits above the lower 3 of the index/bit of the event to enable is the byte
and the lower 3 bits (& 7) is the actual bit to set.

For example if the user_event with the index 1024 is enabled, we need to
figure out which byte and bit represents that event when a probe is
attached.

I got into detail of this in the documentation for both a byte and long
wise checking of these values.

Hope that helps explain it.

> Is STATUS_OTHER suppose to be part of STATUS_MASK()?
> 
> -- Steve

Thanks,
-Beau

  reply	other threads:[~2022-07-27  2:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-25 18:46 [PATCH v2 0/7] tracing/user_events: Update user_events ABI from Beau Belgrave
2022-04-25 18:46 ` [PATCH v2 1/7] tracing/user_events: Fix repeated word in comments Beau Belgrave
2022-04-25 18:46 ` [PATCH v2 2/7] tracing/user_events: Use NULL for strstr checks Beau Belgrave
2022-04-25 18:46 ` [PATCH v2 3/7] tracing/user_events: Use WRITE instead of READ for io vector import Beau Belgrave
2022-04-25 18:46 ` [PATCH v2 4/7] tracing/user_events: Ensure user provided strings are safely formatted Beau Belgrave
2022-04-25 18:46 ` [PATCH v2 5/7] tracing/user_events: Use refcount instead of atomic for ref tracking Beau Belgrave
2022-04-25 18:46 ` [PATCH v2 6/7] tracing/user_events: Use bits vs bytes for enabled status page data Beau Belgrave
2022-07-26 22:01   ` Steven Rostedt
2022-07-27  0:02     ` Beau Belgrave
2022-07-27  0:14       ` Steven Rostedt
2022-07-27  2:01         ` Beau Belgrave [this message]
2022-07-27 13:45           ` Steven Rostedt
2022-07-27 19:01             ` Beau Belgrave
2022-04-25 18:46 ` [PATCH v2 7/7] tracing/user_events: Update ABI documentation to align to bits vs bytes 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=20220727020147.GA1705@kbox \
    --to=beaub@linux.microsoft.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-devel@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.