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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6F845C4332F for ; Tue, 13 Dec 2022 19:44:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235744AbiLMToQ (ORCPT ); Tue, 13 Dec 2022 14:44:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235584AbiLMToN (ORCPT ); Tue, 13 Dec 2022 14:44:13 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4928E0BB for ; Tue, 13 Dec 2022 11:44:11 -0800 (PST) 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 806F46171D for ; Tue, 13 Dec 2022 19:44:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35099C433EF; Tue, 13 Dec 2022 19:44:10 +0000 (UTC) Date: Tue, 13 Dec 2022 14:44:08 -0500 From: Steven Rostedt To: Douglas Raillard Cc: linux-kernel@vger.kernel.org, Masami Hiramatsu , Andrew Morton , Valentin Schneider Subject: Re: [for-next][PATCH 02/11] tracing: Add __cpumask to denote a trace event field that is a cpumask_t Message-ID: <20221213144408.0b78d2c3@gandalf.local.home> In-Reply-To: <48c3eaa4-e896-16c4-af7f-a7e4f0541f01@arm.com> References: <20221124145019.782980678@goodmis.org> <20221124145045.743308431@goodmis.org> <6dda5e1d-9416-b55e-88f3-31d148bc925f@arm.com> <20221212111256.3cf68f3e@gandalf.local.home> <8448372a-6911-e920-b630-15af850adcae@arm.com> <20221212185330.639bf491@gandalf.local.home> <764f8b9a-2111-c260-7f2c-89eb9f0ac7a3@arm.com> <20221213101111.335ae0e7@gandalf.local.home> <48c3eaa4-e896-16c4-af7f-a7e4f0541f01@arm.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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Dec 2022 17:40:06 +0000 Douglas Raillard wrote: > > I prefer not to have "quick&dirty" ;-) > > I'm not saying that I would like to see such quick and dirty events upstream, but the reality around me is > that ftrace events is the only sane way of having an idea what the scheduler does. This means people need > to create experiments all the time with ad-hoc trace events, on top of the trace events that we attach to > tracepoints via a module. Currently, people use trace_printk() for that, which comes with some significant > amount of work and pain (mostly regex speed). Have you seen custom events? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/samples/trace_events/trace_custom_sched.h > > That said having just looked at bprint, I could probably support trace_printk() format strings with simple > struct member access (i.e. no __printflags shenanigans etc) as normal events relatively easily. It's even > possible to use the fmt string pointer as an "event ID". Still a shame that all the event field format infra > basically gets duplicated in a printf format string ... It's the easiest thing to do in the kernel. The below is probably too much work for people to use. The fact that it's just a string and does not have any type information is one of the main reasons I force it not to be in mainline (hence the nasty banner when it is added). > > > > >> > >> #define SIMPLE_TRACE_EVENT(type, fields) \ > >> struct type fields; > >> TRACE_EVENT(type, \ > >> TP_PROTO(struct type *data), \ > >> TP_ARGS(data), \ > >> TP_STRUCT__entry(__field(struct type, data)), \ > >> TP_fast_assign(__entry->data = *data;), \ > >> TP_printk("print in raw mode to display the data"), \ > >> ); > >> #define SIMPLE_TRACE(type, fields) trace_struct_##type(&(struct type)fields) > >> > >> > >> SIMPLE_TRACE_EVENT(myevent, { > >> char name[11]; > >> int foobar; > >> }); > >> > >> SIMPLE_TRACE(myevent, {.name = "hello", .foobar = 42}); > > > > > >> > >> The format string could be either kernel-generated based on BTF or userspace could be expected > >> to make its own use of BTF. > > > > What's the use case for the above? > > An equivalent to trace_printk() that exposes its fields in the "normal" way rather than having to parse > the format string and a comma-separated list of C expressions. Life is too short to write C interpreters. > Parsing BTF is at least a finite amount of work. But I guess it would be easy to handle only "REC->field" > expressions. But the above isn't that much simpler than writing a trace event. When I use trace_printk(), I seldom use it with tooling. And for the few times I have written tools to parse printk, the printk formats are very easily parsed, as I control them. Heck, I'd just do colon delimited string. -- Steve