From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.librecores.org (lists.librecores.org [88.198.125.70]) by smtp.lore.kernel.org (Postfix) with ESMTP id 079DFC433F5 for ; Tue, 11 Oct 2022 20:35:11 +0000 (UTC) Received: from [172.31.1.100] (localhost.localdomain [127.0.0.1]) by mail.librecores.org (Postfix) with ESMTP id 8BC2F24BE9; Tue, 11 Oct 2022 22:35:10 +0200 (CEST) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mail.librecores.org (Postfix) with ESMTPS id 99D0A24BE7 for ; Tue, 11 Oct 2022 22:35:08 +0200 (CEST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7DCF9612CD; Tue, 11 Oct 2022 20:35:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0CA5C433C1; Tue, 11 Oct 2022 20:34:59 +0000 (UTC) Date: Tue, 11 Oct 2022 16:34:53 -0400 From: Steven Rostedt To: Valentin Schneider Subject: Re: [RFC PATCH 0/5] Generic IPI sending tracepoint Message-ID: <20221011163453.2133ab4a@rorschach.local.home> In-Reply-To: References: <20221007154145.1877054-1-vschneid@redhat.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: openrisc@lists.librecores.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion around the OpenRISC processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juri Lelli , Mark Rutland , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Sebastian Andrzej Siewior , Dave Hansen , linux-mips@vger.kernel.org, Guo Ren , "H. Peter Anvin" , sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, Marc Zyngier , linux-hexagon@vger.kernel.org, x86@kernel.org, Russell King , linux-csky@vger.kernel.org, Ingo Molnar , linux-snps-arc@lists.infradead.org, linux-xtensa@linux-xtensa.org, "Paul E. McKenney" , Frederic Weisbecker , Nicholas Piggin , openrisc@lists.librecores.org, Borislav Petkov , loongarch@lists.linux.dev, Thomas Gleixner , linux-arm-kernel@lists.infradead.org, linux-parisc@vger.kernel.org, Daniel Bristot de Oliveira , Marcelo Tosatti , linux-kernel@vger.kernel.org, Douglas RAILLARD , linux-alpha@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, "David S. Miller" Errors-To: openrisc-bounces@lists.librecores.org Sender: "OpenRISC" On Tue, 11 Oct 2022 17:17:04 +0100 Valentin Schneider 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