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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 011A7C61DA4 for ; Thu, 9 Feb 2023 14:42:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Mime-Version:References:In-Reply-To: Message-Id:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FMyMh/lxqNBwPwXXV5Ixly3Dz8enmGUkDhh5Xh4h1rQ=; b=ez578yUXxO/I5e pKUIyNax3MJjcWKw6yl0WtnRnNSJgzhd6xUuCw8H6lI9OLWZ9AGeoZJoqcFbkrxef1f9SP2JsH05u OVpExbLjohUbwJTBu+v0o6QRLzvsQ4mNDZVOjGV8Ohgd8E74bfICc25emXQpcizVsksvXelZf4pOF qlHa1FYU3Bzdt6puIA7I6S3fd4HCUF3R+/vk/gkFHdhrztpkz1NMy0dAItQF58QwKzJAP55RcxJE+ C6Gy4NGzAt36voXEAzy8UxmPmgwG9yRQuiWDvB53XC4zLWlCcmZ5bBhJeAhkuTjiwPdVXiTIhEl5+ U8O7qWyt+R8U8HmIltfA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQ872-00220a-Rh; Thu, 09 Feb 2023 14:41:24 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQ86x-0021yx-TG for linux-arm-kernel@lists.infradead.org; Thu, 09 Feb 2023 14:41:22 +0000 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 42C4761AC9; Thu, 9 Feb 2023 14:41:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E462EC433EF; Thu, 9 Feb 2023 14:41:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675953678; bh=TZ5nyh/Nz50g4Ou5F8th8cMJcRG25BNPZLtFN7x2xjI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=pu76DWdLkYzQE4D2cP0ZWJoo2y3ROVjnMDorXBkWR8B6ATdHFA257whhlSlz/AhHA b2cJ4XWmTYB+ZmVYFv9aVr/+r/yjTgvEIqQTZHysD5C2MkIqTw6N8cMn3MHXOCxW6a iFA51/QtcqndrrFScWobLMkChiOonDL8tkTf94HRhHXaQX9BeKHl7xZsAyr5fhrIpm s40oKdIgZhgoVOoVTtLLvQEiBWAhm4ZidNZqUyLwpX0Lh8Ejw98F55rSWMgl99tkRi MFG1/Ba5jDfjo4HmeQvAABpbET3+GWAngv9w3xZlzuoltr8FzvbvAenfvMbNZW3d1o Q8EBt8SxRoNGQ== Date: Thu, 9 Feb 2023 23:41:13 +0900 From: Masami Hiramatsu (Google) To: Randy Dunlap Cc: linux-kernel@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Daniel Bristot de Oliveira , linux-trace-kernel@vger.kernel.org, Mathieu Poirier , Suzuki K Poulose , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, Jonathan Corbet , linux-doc@vger.kernel.org, Mukesh Ojha Subject: Re: [PATCH 21/24] Documentation: trace: correct spelling Message-Id: <20230209234113.47c44d04f81204a692f387d3@kernel.org> In-Reply-To: <20230209071400.31476-22-rdunlap@infradead.org> References: <20230209071400.31476-1-rdunlap@infradead.org> <20230209071400.31476-22-rdunlap@infradead.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230209_064120_088940_72AA4BE0 X-CRM114-Status: GOOD ( 38.90 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 8 Feb 2023 23:13:57 -0800 Randy Dunlap wrote: > Correct spelling problems for Documentation/trace/ as reported > by codespell. > > Signed-off-by: Randy Dunlap > Cc: Steven Rostedt > Cc: Masami Hiramatsu > Cc: Daniel Bristot de Oliveira > Cc: linux-trace-kernel@vger.kernel.org > Cc: Mathieu Poirier > Cc: Suzuki K Poulose > Cc: coresight@lists.linaro.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: Jonathan Corbet > Cc: linux-doc@vger.kernel.org > Reviewed-by: Mukesh Ojha > Acked-by: Steven Rostedt (Google) > Acked-by: Suzuki K Poulose # for coresight Looks good to me. Acked-by: Masami Hiramatsu (Google) Thanks, > --- > Documentation/trace/coresight/coresight-etm4x-reference.rst | 2 +- > Documentation/trace/events.rst | 6 +++--- > Documentation/trace/fprobe.rst | 2 +- > Documentation/trace/ftrace-uses.rst | 2 +- > Documentation/trace/hwlat_detector.rst | 2 +- > Documentation/trace/uprobetracer.rst | 2 +- > 7 files changed, 9 insertions(+), 9 deletions(-) > > diff -- a/Documentation/trace/coresight/coresight-etm4x-reference.rst b/Documentation/trace/coresight/coresight-etm4x-reference.rst > --- a/Documentation/trace/coresight/coresight-etm4x-reference.rst > +++ b/Documentation/trace/coresight/coresight-etm4x-reference.rst > @@ -675,7 +675,7 @@ Bit assignments shown below:- > reconstructed using only conditional branches. > > There is currently no support in Perf for supplying modified binaries to the decoder, so this > - feature is only inteded to be used for debugging purposes or with a 3rd party tool. > + feature is only intended to be used for debugging purposes or with a 3rd party tool. > > Choosing this option will result in a significant increase in the amount of trace generated - > possible danger of overflows, or fewer instructions covered. Note, that this option also > diff -- a/Documentation/trace/events.rst b/Documentation/trace/events.rst > --- a/Documentation/trace/events.rst > +++ b/Documentation/trace/events.rst > @@ -903,7 +903,7 @@ functions can be used. > > To create a kprobe event, an empty or partially empty kprobe event > should first be created using kprobe_event_gen_cmd_start(). The name > -of the event and the probe location should be specfied along with one > +of the event and the probe location should be specified along with one > or args each representing a probe field should be supplied to this > function. Before calling kprobe_event_gen_cmd_start(), the user > should create and initialize a dynevent_cmd object using > @@ -983,7 +983,7 @@ The basic idea is simple and amounts to > layer that can be used to generate trace event commands. The > generated command strings can then be passed to the command-parsing > and event creation code that already exists in the trace event > -subystem for creating the corresponding trace events. > +subsystem for creating the corresponding trace events. > > In a nutshell, the way it works is that the higher-level interface > code creates a struct dynevent_cmd object, then uses a couple > @@ -1056,7 +1056,7 @@ to add an operator between the pair (her > appended onto the end of the arg pair (here ';'). > > There's also a dynevent_str_add() function that can be used to simply > -add a string as-is, with no spaces, delimeters, or arg check. > +add a string as-is, with no spaces, delimiters, or arg check. > > Any number of dynevent_*_add() calls can be made to build up the string > (until its length surpasses cmd->maxlen). When all the arguments have > diff -- a/Documentation/trace/fprobe.rst b/Documentation/trace/fprobe.rst > --- a/Documentation/trace/fprobe.rst > +++ b/Documentation/trace/fprobe.rst > @@ -111,7 +111,7 @@ saved at function entry and passed to ex > the instruction pointer of @regs may be different from the @entry_ip > in the entry_handler. If you need traced instruction pointer, you need > to use @entry_ip. On the other hand, in the exit_handler, the instruction > - pointer of @regs is set to the currect return address. > + pointer of @regs is set to the correct return address. > > Share the callbacks with kprobes > ================================ > diff -- a/Documentation/trace/ftrace-uses.rst b/Documentation/trace/ftrace-uses.rst > --- a/Documentation/trace/ftrace-uses.rst > +++ b/Documentation/trace/ftrace-uses.rst > @@ -193,7 +193,7 @@ FTRACE_OPS_FL_RECURSION > Not, if this flag is set, then the callback will always be called > with preemption disabled. If it is not set, then it is possible > (but not guaranteed) that the callback will be called in > - preemptable context. > + preemptible context. > > FTRACE_OPS_FL_IPMODIFY > Requires FTRACE_OPS_FL_SAVE_REGS set. If the callback is to "hijack" > diff -- a/Documentation/trace/hwlat_detector.rst b/Documentation/trace/hwlat_detector.rst > --- a/Documentation/trace/hwlat_detector.rst > +++ b/Documentation/trace/hwlat_detector.rst > @@ -14,7 +14,7 @@ originally written for use by the "RT" p > kernel is highly latency sensitive. > > SMIs are not serviced by the Linux kernel, which means that it does not > -even know that they are occuring. SMIs are instead set up by BIOS code > +even know that they are occurring. SMIs are instead set up by BIOS code > and are serviced by BIOS code, usually for "critical" events such as > management of thermal sensors and fans. Sometimes though, SMIs are used for > other tasks and those tasks can spend an inordinate amount of time in the > diff -- a/Documentation/trace/uprobetracer.rst b/Documentation/trace/uprobetracer.rst > --- a/Documentation/trace/uprobetracer.rst > +++ b/Documentation/trace/uprobetracer.rst > @@ -55,7 +55,7 @@ Synopsis of uprobe_tracer > > (\*1) only for return probe. > (\*2) this is useful for fetching a field of data structures. > - (\*3) Unlike kprobe event, "u" prefix will just be ignored, becuse uprobe > + (\*3) Unlike kprobe event, "u" prefix will just be ignored, because uprobe > events can access only user-space memory. > > Types -- Masami Hiramatsu (Google) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel