From: Steven Rostedt <rostedt@goodmis.org>
To: Valentin Schneider <vschneid@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org,
loongarch@lists.linux.dev, linux-mips@vger.kernel.org,
openrisc@lists.librecores.org, linux-parisc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
x86@kernel.org, "Paul E. McKenney" <paulmck@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Juri Lelli <juri.lelli@redhat.com>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Frederic Weisbecker <frederic@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Marc Zyngier <maz@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Russell King <linux@armlinux.org.uk>,
Nicholas Piggin <npiggin@gmail.com>, Guo Ren <guoren@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Douglas RAILLARD <douglas.raillard@arm.com>
Subject: Re: [RFC PATCH 0/5] Generic IPI sending tracepoint
Date: Tue, 11 Oct 2022 16:34:53 -0400 [thread overview]
Message-ID: <20221011163453.2133ab4a@rorschach.local.home> (raw)
In-Reply-To: <xhsmhilkqfi7z.mognet@vschneid.remote.csb>
On Tue, 11 Oct 2022 17:17:04 +0100
Valentin Schneider <vschneid@redhat.com> wrote:
> tep_get_field_val() just yields an unsigned long long of value 0x200018,
> which AFAICT is just the [length, offset] thing associated with dynamic
> arrays. Not really usable, and I don't see anything exported in the lib to
> extract and use those values.
Correct.
>
> tep_get_field_raw() is better, it handles the dynamic array for us and
> yields a pointer to the cpumask array at the tail of the record. With that
> it's easy to get an output such as: cpumask[size=32]=[4,0,0,0,]. Still,
> this isn't a native type for many programming languages.
Yeah, this is the interface that I would have used. And it would likely
require some kind of wrapper to make it into what you prefer.
Note, I've been complaining for some time now how much I hate the
libtraceevent interface, and want to rewrite it. (I just spoke to
someone that wants to implement it in Rust). But the question comes
down to how to make it backward compatible. Perhaps we don't and just
up the major version number (libtraceevent 2.0).
What would you recommend as an API to process cpumasks better?
-- Steve
prev parent reply other threads:[~2022-10-11 20:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-07 15:41 [RFC PATCH 0/5] Generic IPI sending tracepoint Valentin Schneider
2022-10-07 15:45 ` [RFC PATCH 1/5] trace: Add trace_ipi_send_{cpu, cpumask} Valentin Schneider
2022-10-07 15:45 ` [RFC PATCH 2/5] sched, smp: Trace send_call_function_single_ipi() Valentin Schneider
2022-10-07 15:45 ` [RFC PATCH 3/5] smp: Add a multi-CPU variant to send_call_function_single_ipi() Valentin Schneider
2022-10-07 15:45 ` [RFC PATCH 4/5] irq_work: Trace calls to arch_irq_work_raise() Valentin Schneider
2022-10-08 19:34 ` Steven Rostedt
2022-10-11 15:02 ` Valentin Schneider
2022-10-07 15:45 ` [RFC PATCH 5/5] treewide: Rename and trace arch-definitions of smp_send_reschedule() Valentin Schneider
2022-10-08 0:23 ` Guo Ren
2022-10-07 20:01 ` [RFC PATCH 0/5] Generic IPI sending tracepoint Marcelo Tosatti
2022-10-08 19:40 ` Steven Rostedt
2022-10-11 16:17 ` Valentin Schneider
2022-10-11 16:22 ` Daniel Bristot de Oliveira
2022-10-11 16:40 ` Valentin Schneider
2022-10-11 20:41 ` Steven Rostedt
2022-10-11 20:34 ` Steven Rostedt [this message]
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=20221011163453.2133ab4a@rorschach.local.home \
--to=rostedt@goodmis.org \
--cc=bigeasy@linutronix.de \
--cc=bp@alien8.de \
--cc=bristot@redhat.com \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=douglas.raillard@arm.com \
--cc=frederic@kernel.org \
--cc=guoren@kernel.org \
--cc=hpa@zytor.com \
--cc=juri.lelli@redhat.com \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mingo@redhat.com \
--cc=mtosatti@redhat.com \
--cc=npiggin@gmail.com \
--cc=openrisc@lists.librecores.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=vschneid@redhat.com \
--cc=x86@kernel.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).