linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/1] tracing: fix spelling mistakes
@ 2021-05-25  6:20 Zhen Lei
  2021-05-25  6:20 ` [PATCH 1/1] " Zhen Lei
  0 siblings, 1 reply; 8+ messages in thread
From: Zhen Lei @ 2021-05-25  6:20 UTC (permalink / raw)
  To: Steven Rostedt, Ingo Molnar, linux-kernel; +Cc: Zhen Lei

The files being checked:
kernel/trace/
include/linux/trace*.h


Zhen Lei (1):
  tracing: fix spelling mistakes

 include/linux/tracepoint.h           | 2 +-
 kernel/trace/Kconfig                 | 2 +-
 kernel/trace/ring_buffer.c           | 2 +-
 kernel/trace/ring_buffer_benchmark.c | 2 +-
 kernel/trace/trace.c                 | 6 +++---
 kernel/trace/trace_branch.c          | 2 +-
 kernel/trace/trace_events.c          | 2 +-
 kernel/trace/trace_events_filter.c   | 2 +-
 kernel/trace/trace_seq.c             | 2 +-
 9 files changed, 11 insertions(+), 11 deletions(-)

-- 
2.25.1



^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH 1/1] tracing: fix spelling mistakes
  2021-05-25  6:20 [PATCH 0/1] tracing: fix spelling mistakes Zhen Lei
@ 2021-05-25  6:20 ` Zhen Lei
  2021-05-29  1:13   ` Steven Rostedt
  0 siblings, 1 reply; 8+ messages in thread
From: Zhen Lei @ 2021-05-25  6:20 UTC (permalink / raw)
  To: Steven Rostedt, Ingo Molnar, linux-kernel; +Cc: Zhen Lei

Fix some spelling mistakes in comments:
wont ==> won't
overwite ==> overwrite
outputing ==> outputting
overlayed ==> overlaid
singe ==> single

The name of an unused function parameter:
ingore ==> ignore

And the name of the cpuhp step:
preapre ==> prepare

Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
 include/linux/tracepoint.h           | 2 +-
 kernel/trace/Kconfig                 | 2 +-
 kernel/trace/ring_buffer.c           | 2 +-
 kernel/trace/ring_buffer_benchmark.c | 2 +-
 kernel/trace/trace.c                 | 6 +++---
 kernel/trace/trace_branch.c          | 2 +-
 kernel/trace/trace_events.c          | 2 +-
 kernel/trace/trace_events_filter.c   | 2 +-
 kernel/trace/trace_seq.c             | 2 +-
 9 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 13f65420f188..b0f19b799d77 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -507,7 +507,7 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
  *	* This is how the tracepoint will appear under ftrace
  *	* plugins that make use of this tracepoint.
  *	*
- *	* (raw-binary tracing wont actually perform this step.)
+ *	* (raw-binary tracing won't actually perform this step.)
  *	*
  *
  *	TP_printk("task %s:%d [%d] ==> %s:%d [%d]",
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 7fa82778c3e6..110ff9a6175c 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -795,7 +795,7 @@ config RING_BUFFER_RECORD_RECURSION
 	default y
 	help
 	  The ring buffer has its own internal recursion. Although when
-	  recursion happens it wont cause harm because of the protection,
+	  recursion happens it won't cause harm because of the protection,
 	  but it does cause an unwanted overhead. Enabling this option will
 	  place where recursion was detected into the ftrace "recursed_functions"
 	  file.
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 2c0ee6484990..3cb9733719e5 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -5902,7 +5902,7 @@ static __init int test_ringbuffer(void)
 	/*
 	 * Show buffer is enabled before setting rb_test_started.
 	 * Yes there's a small race window where events could be
-	 * dropped and the thread wont catch it. But when a ring
+	 * dropped and the thread won't catch it. But when a ring
 	 * buffer gets enabled, there will always be some kind of
 	 * delay before other CPUs see it. Thus, we don't care about
 	 * those dropped events. We care about events dropped after
diff --git a/kernel/trace/ring_buffer_benchmark.c b/kernel/trace/ring_buffer_benchmark.c
index 78e576575b79..62a3d26e591e 100644
--- a/kernel/trace/ring_buffer_benchmark.c
+++ b/kernel/trace/ring_buffer_benchmark.c
@@ -431,7 +431,7 @@ static int __init ring_buffer_benchmark_init(void)
 {
 	int ret;
 
-	/* make a one meg buffer in overwite mode */
+	/* make a one meg buffer in overwrite mode */
 	buffer = ring_buffer_alloc(1000000, RB_FL_OVERWRITE);
 	if (!buffer)
 		return -ENOMEM;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index a21ef9cd2aae..b869a53700a6 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -122,7 +122,7 @@ cpumask_var_t __read_mostly	tracing_buffer_mask;
  * If there is an oops (or kernel panic) and the ftrace_dump_on_oops
  * is set, then ftrace_dump is called. This will output the contents
  * of the ftrace buffers to the console.  This is very useful for
- * capturing traces that lead to crashes and outputing it to a
+ * capturing traces that lead to crashes and outputting it to a
  * serial console.
  *
  * It is default off, but you can enable it with either specifying
@@ -9323,7 +9323,7 @@ init_tracer_tracefs(struct trace_array *tr, struct dentry *d_tracer)
 	ftrace_init_tracefs(tr, d_tracer);
 }
 
-static struct vfsmount *trace_automount(struct dentry *mntpt, void *ingore)
+static struct vfsmount *trace_automount(struct dentry *mntpt, void *ignore)
 {
 	struct vfsmount *mnt;
 	struct file_system_type *type;
@@ -9858,7 +9858,7 @@ __init static int tracer_alloc_buffers(void)
 	 * buffer. The memory will be removed once the "instance" is removed.
 	 */
 	ret = cpuhp_setup_state_multi(CPUHP_TRACE_RB_PREPARE,
-				      "trace/RB:preapre", trace_rb_cpu_prepare,
+				      "trace/RB:prepare", trace_rb_cpu_prepare,
 				      NULL);
 	if (ret < 0)
 		goto out_free_cpumask;
diff --git a/kernel/trace/trace_branch.c b/kernel/trace/trace_branch.c
index e47fdb4c92fb..c69a192ca728 100644
--- a/kernel/trace/trace_branch.c
+++ b/kernel/trace/trace_branch.c
@@ -274,7 +274,7 @@ static void branch_stat_show(struct seq_file *m,
 	long percent;
 
 	/*
-	 * The miss is overlayed on correct, and hit on incorrect.
+	 * The miss is overlaid on correct, and hit on incorrect.
 	 */
 	percent = get_incorrect_percent(p);
 
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 80e96989770e..3023c0878d32 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -594,7 +594,7 @@ static int __ftrace_event_enable_disable(struct trace_event_file *file,
 		 *
 		 * When soft_disable is not set but the SOFT_MODE flag is,
 		 * we do nothing. Do not disable the tracepoint, otherwise
-		 * "soft enable"s (clearing the SOFT_DISABLED bit) wont work.
+		 * "soft enable"s (clearing the SOFT_DISABLED bit) won't work.
 		 */
 		if (soft_disable) {
 			if (atomic_dec_return(&file->sm_ref) > 0)
diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
index c9124038b140..aeb4e9892a72 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -91,7 +91,7 @@ static bool is_not(const char *str)
 }
 
 /**
- * prog_entry - a singe entry in the filter program
+ * prog_entry - a single entry in the filter program
  * @target:	     Index to jump to on a branch (actually one minus the index)
  * @when_to_branch:  The value of the result of the predicate to do a branch
  * @pred:	     The predicate to execute.
diff --git a/kernel/trace/trace_seq.c b/kernel/trace/trace_seq.c
index 9c90b3a7dce2..ec63d0ae6a22 100644
--- a/kernel/trace/trace_seq.c
+++ b/kernel/trace/trace_seq.c
@@ -18,7 +18,7 @@
  *
  * A write to the buffer will either succeed or fail. That is, unlike
  * sprintf() there will not be a partial write (well it may write into
- * the buffer but it wont update the pointers). This allows users to
+ * the buffer but it won't update the pointers). This allows users to
  * try to write something into the trace_seq buffer and if it fails
  * they can flush it and try again.
  *
-- 
2.25.1



^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/1] tracing: fix spelling mistakes
  2021-05-25  6:20 ` [PATCH 1/1] " Zhen Lei
@ 2021-05-29  1:13   ` Steven Rostedt
  2021-05-29  2:01     ` Leizhen (ThunderTown)
  0 siblings, 1 reply; 8+ messages in thread
From: Steven Rostedt @ 2021-05-29  1:13 UTC (permalink / raw)
  To: Zhen Lei; +Cc: Ingo Molnar, linux-kernel

On Tue, 25 May 2021 14:20:47 +0800
Zhen Lei <thunder.leizhen@huawei.com> wrote:

> Fix some spelling mistakes in comments:
> wont ==> won't

I prefer not to fix that spelling. I sometimes purposely leave off
single quotes. It's no that big of a deal, and doesn't deserve the
churn.

-- Steve

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/1] tracing: fix spelling mistakes
  2021-05-29  1:13   ` Steven Rostedt
@ 2021-05-29  2:01     ` Leizhen (ThunderTown)
  2021-05-29  2:11       ` Steven Rostedt
  0 siblings, 1 reply; 8+ messages in thread
From: Leizhen (ThunderTown) @ 2021-05-29  2:01 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Ingo Molnar, linux-kernel



On 2021/5/29 9:13, Steven Rostedt wrote:
> On Tue, 25 May 2021 14:20:47 +0800
> Zhen Lei <thunder.leizhen@huawei.com> wrote:
> 
>> Fix some spelling mistakes in comments:
>> wont ==> won't
> 
> I prefer not to fix that spelling. I sometimes purposely leave off
> single quotes. It's no that big of a deal, and doesn't deserve the
> churn.

Yes, all people can get it right by their wits. "Wont" doesn't affect
their reading speed. But most people might think it's best to add the
missing single quote.

The minority obeys the majority?

In addition, "wont" is an independent word. See:
https://www.grammarly.com/blog/wont-vs-wont/
Wont is usually used as a noun meaning “a type of behavior specific to a person,” or “a habit.”

> 
> -- Steve
> 
> .
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/1] tracing: fix spelling mistakes
  2021-05-29  2:01     ` Leizhen (ThunderTown)
@ 2021-05-29  2:11       ` Steven Rostedt
  2021-05-29  2:40         ` Leizhen (ThunderTown)
  2021-06-16 12:12         ` Leizhen (ThunderTown)
  0 siblings, 2 replies; 8+ messages in thread
From: Steven Rostedt @ 2021-05-29  2:11 UTC (permalink / raw)
  To: Leizhen (ThunderTown); +Cc: Ingo Molnar, linux-kernel

On Sat, 29 May 2021 10:01:31 +0800
"Leizhen (ThunderTown)" <thunder.leizhen@huawei.com> wrote:

> On 2021/5/29 9:13, Steven Rostedt wrote:
> > On Tue, 25 May 2021 14:20:47 +0800
> > Zhen Lei <thunder.leizhen@huawei.com> wrote:
> >   
> >> Fix some spelling mistakes in comments:
> >> wont ==> won't  
> > 
> > I prefer not to fix that spelling. I sometimes purposely leave off
> > single quotes. It's no that big of a deal, and doesn't deserve the
> > churn.  
> 
> Yes, all people can get it right by their wits. "Wont" doesn't affect
> their reading speed. But most people might think it's best to add the
> missing single quote.
> 
> The minority obeys the majority?

I really don't care. In my opinion, it's unnecessary churn, that just
adds noise to the git logs.

-- Steve

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/1] tracing: fix spelling mistakes
  2021-05-29  2:11       ` Steven Rostedt
@ 2021-05-29  2:40         ` Leizhen (ThunderTown)
  2021-05-29  3:03           ` Leizhen (ThunderTown)
  2021-06-16 12:12         ` Leizhen (ThunderTown)
  1 sibling, 1 reply; 8+ messages in thread
From: Leizhen (ThunderTown) @ 2021-05-29  2:40 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Ingo Molnar, linux-kernel



On 2021/5/29 10:11, Steven Rostedt wrote:
> On Sat, 29 May 2021 10:01:31 +0800
> "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com> wrote:
> 
>> On 2021/5/29 9:13, Steven Rostedt wrote:
>>> On Tue, 25 May 2021 14:20:47 +0800
>>> Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>   
>>>> Fix some spelling mistakes in comments:
>>>> wont ==> won't  
>>>
>>> I prefer not to fix that spelling. I sometimes purposely leave off
>>> single quotes. It's no that big of a deal, and doesn't deserve the
>>> churn.  
>>
>> Yes, all people can get it right by their wits. "Wont" doesn't affect
>> their reading speed. But most people might think it's best to add the
>> missing single quote.
>>
>> The minority obeys the majority?
> 
> I really don't care. In my opinion, it's unnecessary churn, that just
> adds noise to the git logs.

git grep -wn wont | wc -l
83

OK, I just did a search for "wont", and there are currently 83 places in
use. Language is not mathematics, there is no absolute right or wrong. If
a lot of people are using it incorrectly or specifically, then the new one
is also right.

Wow, should I send v2 to remove "wont ==> won't"?

> 
> -- Steve
> 
> .
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/1] tracing: fix spelling mistakes
  2021-05-29  2:40         ` Leizhen (ThunderTown)
@ 2021-05-29  3:03           ` Leizhen (ThunderTown)
  0 siblings, 0 replies; 8+ messages in thread
From: Leizhen (ThunderTown) @ 2021-05-29  3:03 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Ingo Molnar, linux-kernel



On 2021/5/29 10:40, Leizhen (ThunderTown) wrote:
> 
> 
> On 2021/5/29 10:11, Steven Rostedt wrote:
>> On Sat, 29 May 2021 10:01:31 +0800
>> "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com> wrote:
>>
>>> On 2021/5/29 9:13, Steven Rostedt wrote:
>>>> On Tue, 25 May 2021 14:20:47 +0800
>>>> Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>>   
>>>>> Fix some spelling mistakes in comments:
>>>>> wont ==> won't  
>>>>
>>>> I prefer not to fix that spelling. I sometimes purposely leave off
>>>> single quotes. It's no that big of a deal, and doesn't deserve the
>>>> churn.  
>>>
>>> Yes, all people can get it right by their wits. "Wont" doesn't affect
>>> their reading speed. But most people might think it's best to add the
>>> missing single quote.
>>>
>>> The minority obeys the majority?
>>
>> I really don't care. 

Thanks.

>> In my opinion, it's unnecessary churn, that just
>> adds noise to the git logs.
> 
> git grep -wn wont | wc -l
> 83
> 
> OK, I just did a search for "wont", and there are currently 83 places in
> use. Language is not mathematics, there is no absolute right or wrong. If
> a lot of people are using it incorrectly or specifically, then the new one
> is also right.
> 
> Wow, should I send v2 to remove "wont ==> won't"?

Actually, I'd prefer to change it to "won't".

> 
>>
>> -- Steve
>>
>> .
>>


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/1] tracing: fix spelling mistakes
  2021-05-29  2:11       ` Steven Rostedt
  2021-05-29  2:40         ` Leizhen (ThunderTown)
@ 2021-06-16 12:12         ` Leizhen (ThunderTown)
  1 sibling, 0 replies; 8+ messages in thread
From: Leizhen (ThunderTown) @ 2021-06-16 12:12 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Ingo Molnar, linux-kernel



On 2021/5/29 10:11, Steven Rostedt wrote:
> On Sat, 29 May 2021 10:01:31 +0800
> "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com> wrote:
> 
>> On 2021/5/29 9:13, Steven Rostedt wrote:
>>> On Tue, 25 May 2021 14:20:47 +0800
>>> Zhen Lei <thunder.leizhen@huawei.com> wrote:
>>>   
>>>> Fix some spelling mistakes in comments:
>>>> wont ==> won't  
>>>
>>> I prefer not to fix that spelling. I sometimes purposely leave off
>>> single quotes. It's no that big of a deal, and doesn't deserve the
>>> churn.  
>>
>> Yes, all people can get it right by their wits. "Wont" doesn't affect
>> their reading speed. But most people might think it's best to add the
>> missing single quote.
>>
>> The minority obeys the majority?
> 
> I really don't care. In my opinion, it's unnecessary churn, that just
> adds noise to the git logs.

Hi, Steve:

$ cat scripts/spelling.txt | grep wont
wont||won't

"wont" has been recognized as a misspelling.

> 
> -- Steve
> 
> .
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-06-16 12:12 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-25  6:20 [PATCH 0/1] tracing: fix spelling mistakes Zhen Lei
2021-05-25  6:20 ` [PATCH 1/1] " Zhen Lei
2021-05-29  1:13   ` Steven Rostedt
2021-05-29  2:01     ` Leizhen (ThunderTown)
2021-05-29  2:11       ` Steven Rostedt
2021-05-29  2:40         ` Leizhen (ThunderTown)
2021-05-29  3:03           ` Leizhen (ThunderTown)
2021-06-16 12:12         ` Leizhen (ThunderTown)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).