Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2766449pxu; Mon, 7 Dec 2020 15:23:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJyEmNz9qltXOxpTkHh1azxsGlzKJsFjMQcgmvvKuM6aefQUZtfgNJwxlbx/wiyuSMoZp/Fl X-Received: by 2002:a17:907:7253:: with SMTP id ds19mr22145640ejc.166.1607383406324; Mon, 07 Dec 2020 15:23:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607383406; cv=none; d=google.com; s=arc-20160816; b=kQerQ/Ejj7veXKFLsXZ84YGepPMczXyvGsh6ITsNQ42gKYhhswyGiFEZ/4ara6g3Uj sMzX055AMTQ2P4uA3C8IVDeh5n/Taz7lbX6B1REqYLHIFq0tJusxNHI4m3U/2sXJJeMZ ZEFyDwFWHt/zK5DjC+JT6kaXaXjfQrKVi3G2m5BB8g492+1HKiq8k12i4oEQHJ9INr1P Asl1Nb9U/a2tKXMysByYdCqZKnZubQmVKqp7XEMz9O++H+Ew8ig5bEdyTlOixITymcHA CvS0y7swSRQD2kFV6Zguqhzj7EFp7RQOntlB9c7G7+7QPCd8XE/mVYi9v0gik+pS4XFk h3GQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=AAjfB9xQjh6oXirIFhyE6K7XFbjmPAgRiuU6xxk6UZs=; b=fK9LCglfysyQfBfX0YiZwsOsAe/5HKHRZ/gP6F2M3Q9tFE9CURJI+4tkyMsbz262nq w3+n3ailt1SKNI56Xoe1NbHZbypl/zHdnxG0JNQZhkOWvQ6BG6sHlLj2wTCcD/GmMupe WrYMiS7DIBUpNxsehP6lFX3/wtsCqYrKoiTr6qiXuFaMIVjzi8+7K/oR53LBIn1PnKuZ s1Uj0Y3vcT8d6FERadffpffgbfVFW2Xr2nuPF9PpP2T/2MUJmJxmehDYQNtp11tvhmHx W863PN5XZ3ORPr9fnh0TCn4kT480BmuF+k2vfV1bUWgmYWjDqrZMdKZjlFB/zP7lE1QX iPTA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bz13si7362916ejc.437.2020.12.07.15.23.02; Mon, 07 Dec 2020 15:23:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726501AbgLGXT6 (ORCPT + 99 others); Mon, 7 Dec 2020 18:19:58 -0500 Received: from mail.kernel.org ([198.145.29.99]:55946 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726096AbgLGXT6 (ORCPT ); Mon, 7 Dec 2020 18:19:58 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7A37C23A1C; Mon, 7 Dec 2020 23:19:16 +0000 (UTC) Date: Mon, 7 Dec 2020 18:19:14 -0500 From: Steven Rostedt To: Jonathan Corbet Cc: Tom Zanussi , Artem Bityutskiy , linux-kernel@vger.kernel.org Subject: Re: [PATCH] docs: trace: fix event state structure name Message-ID: <20201207181914.370d4016@gandalf.local.home> In-Reply-To: <96720ed0aac00653f9359679665d0ed4b2cc346d.camel@kernel.org> References: <20201104122113.322452-1-dedekind1@gmail.com> <96720ed0aac00653f9359679665d0ed4b2cc346d.camel@kernel.org> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; 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 Fri, 06 Nov 2020 14:47:46 -0600 Tom Zanussi wrote: > Hi Artem, > > On Wed, 2020-11-04 at 14:21 +0200, Artem Bityutskiy wrote: > > From: Artem Bityutskiy > > > > The documentation refers to a non-existent 'struct synth_trace_state' > > structure. The correct name is 'struct synth_event_trace_state'. > > > > In other words, this patch is a mechanical substitution: > > s/synth_trace_state/synth_event_trace_state/g > > > > Signed-off-by: Artem Bityutskiy > > Thanks for fixing this! > > Reviewed-by: Tom Zanussi > Jon, Can you take this patch? Acked-by: Steven Rostedt (VMware) -- Steve > > > --- > > Documentation/trace/events.rst | 10 +++++----- > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/Documentation/trace/events.rst > > b/Documentation/trace/events.rst > > index f792b1959a33..bdba7b0e19ef 100644 > > --- a/Documentation/trace/events.rst > > +++ b/Documentation/trace/events.rst > > @@ -787,13 +787,13 @@ To trace a synthetic using the piecewise method > > described above, the > > synth_event_trace_start() function is used to 'open' the synthetic > > event trace:: > > > > - struct synth_trace_state trace_state; > > + struct synth_event_trace_state trace_state; > > > > ret = synth_event_trace_start(schedtest_event_file, > > &trace_state); > > > > It's passed the trace_event_file representing the synthetic event > > using the same methods as described above, along with a pointer to a > > -struct synth_trace_state object, which will be zeroed before use and > > +struct synth_event_trace_state object, which will be zeroed before > > use and > > used to maintain state between this and following calls. > > > > Once the event has been opened, which means space for it has been > > @@ -805,7 +805,7 @@ lookup per field. > > > > To assign the values one after the other without lookups, > > synth_event_add_next_val() should be used. Each call is passed the > > -same synth_trace_state object used in the synth_event_trace_start(), > > +same synth_event_trace_state object used in the > > synth_event_trace_start(), > > along with the value to set the next field in the event. After each > > field is set, the 'cursor' points to the next field, which will be > > set > > by the subsequent call, continuing until all the fields have been > > set > > @@ -834,7 +834,7 @@ this method would be (without error-handling > > code):: > > ret = synth_event_add_next_val(395, &trace_state); > > > > To assign the values in any order, synth_event_add_val() should be > > -used. Each call is passed the same synth_trace_state object used in > > +used. Each call is passed the same synth_event_trace_state object > > used in > > the synth_event_trace_start(), along with the field name of the > > field > > to set and the value to set it to. The same sequence of calls as in > > the above examples using this method would be (without error- > > handling > > @@ -856,7 +856,7 @@ can be used but not both at the same time. > > > > Finally, the event won't be actually traced until it's 'closed', > > which is done using synth_event_trace_end(), which takes only the > > -struct synth_trace_state object used in the previous calls:: > > +struct synth_event_trace_state object used in the previous calls:: > > > > ret = synth_event_trace_end(&trace_state); > >