Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1258663pxb; Wed, 4 Nov 2020 04:23:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJx37x/PTGjl6ZAT1kOtlOWdyiW4MwvNuFAxoKfGmoAsn36azeBOgWN4uv4CxrbGOhvwWPrW X-Received: by 2002:a50:d5dd:: with SMTP id g29mr21428997edj.379.1604492592834; Wed, 04 Nov 2020 04:23:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604492592; cv=none; d=google.com; s=arc-20160816; b=beYMAt6IZayTB4h3fI+91T8KrSkw43iDmyHyB8+ZK/8dDGDUSOqMIhep4OUVL2HEdX NE/hbdo+UZeY0oDQffW3QKDCb0K6VVjBbtij9Gy3zXeoF3NsIvkqZ7vAF6BKCbtthRt4 xV8z2PH3vNHwtcMJbJ/P4IugDhKIAx427AKBbxe7D3gxNs0jkMaQn2OnjPutFSj0Fg0D Y23lADrTLOdegxWEalzOAVdp7pqhq7TYKyLKXw9zsO6eUL4bihO9tLR+hc0liTfsRsJz 25w0oELaieH9ItNOYqDYdEnYYsaGabvxpsg10OMk9phuPVrKqo2MpsKBGqHyOhejIXIR EmNQ== 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 :message-id:date:subject:cc:to:from:ironport-sdr:ironport-sdr; bh=D6XG2fE1kEqajbQoMXy6jcUruEDXYs/+RFLD36TsNhI=; b=QnF5i9J2wlRl5MLpClq7tL/93dTY94UuHLBArIVaV8Nlh6O5f0pCndzyg63yRRtV1C t/Z0f4E0DYWYVOw1vGeeeYqmN5msMu5ZdFFW0b9URRMvOUSRuM5Wp5q6LPskE4TAl7/z hCkcxGc1+WddBsr68YBr1hM3AvbIuuL686WAczw7bZxfZ3ePchG9vvUtFJce0Blr0UpN giNjkYGnzoSOETbwrb63QRGeQBLsE27wsPBm+vOkrGj1/UEjNz5HHFG+JRO3cG7gjNXv nKquO8Psgx1pa45xG1D38ZViGb/aQJXo3dywPJzJsgNQmPUfvw+8IIXfiM4I9bCtApsJ bqHw== 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; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b24si1317690eje.190.2020.11.04.04.22.49; Wed, 04 Nov 2020 04:23:12 -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; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729886AbgKDMVQ (ORCPT + 99 others); Wed, 4 Nov 2020 07:21:16 -0500 Received: from mga14.intel.com ([192.55.52.115]:48932 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729309AbgKDMVQ (ORCPT ); Wed, 4 Nov 2020 07:21:16 -0500 IronPort-SDR: lPxghA+2vjOPd9RcJ7Z+/l5xSUorfPyNZxAoYudqwJTWXzmOta5kDjUwda7G0Wkt3j5LUUqXE0 /P0xCT15a1lg== X-IronPort-AV: E=McAfee;i="6000,8403,9794"; a="168420607" X-IronPort-AV: E=Sophos;i="5.77,450,1596524400"; d="scan'208";a="168420607" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2020 04:21:16 -0800 IronPort-SDR: zGtwxVkHwVm4qp/4p1KZPEy5xJRDhRi8LgxeuZxEuasBeyNWCIjii+F9dT9mbMZxPWj1DQvZK0 qCc+CZmMM3bw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,450,1596524400"; d="scan'208";a="336863525" Received: from powerlab.fi.intel.com (HELO powerlab.backendnet) ([10.237.71.25]) by orsmga002.jf.intel.com with ESMTP; 04 Nov 2020 04:21:14 -0800 From: Artem Bityutskiy To: "Steven Rostedt" Cc: Tom Zanussi , linux-kernel@vger.kernel.org, Artem Bityutskiy Subject: [PATCH] docs: trace: fix event state structure name Date: Wed, 4 Nov 2020 14:21:13 +0200 Message-Id: <20201104122113.322452-1-dedekind1@gmail.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- 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); -- 2.26.2