[PATCH] cgroup: Fix typo in comments and documents

Subsystems: control group (cgroup), control group - cpuset, documentation, the rest

STALE1862d

10 messages, 5 authors, 2021-08-01 · open the first message on its own page

[PATCH] cgroup: Fix typo in comments and documents

From: Cai Huoqing <hidden>
Date: 2021-07-30 05:16:22

Fix typo: iff  ==> if

Signed-off-by: Cai Huoqing <redacted>
---
 Documentation/admin-guide/cgroup-v1/cgroups.rst           | 2 +-
 Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst | 4 ++--
 kernel/cgroup/cgroup-v1.c                                 | 4 ++--
 kernel/cgroup/cgroup.c                                    | 6 +++---
 kernel/cgroup/cpuset.c                                    | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v1/cgroups.rst b/Documentation/admin-guide/cgroup-v1/cgroups.rst
index b0688011ed06..fa747466e304 100644
--- a/Documentation/admin-guide/cgroup-v1/cgroups.rst
+++ b/Documentation/admin-guide/cgroup-v1/cgroups.rst
@@ -573,7 +573,7 @@ cgroup_for_each_descendant_pre() for details.
 ``void css_offline(struct cgroup *cgrp);``
 (cgroup_mutex held by caller)
 
-This is the counterpart of css_online() and called iff css_online()
+This is the counterpart of css_online() and called if css_online()
 has succeeded on @cgrp. This signifies the beginning of the end of
 @cgrp. @cgrp is being removed and the subsystem should start dropping
 all references it's holding on @cgrp. When all references are dropped,
diff --git a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
index 582d3427de3f..a908c5226bde 100644
--- a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
+++ b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
@@ -56,7 +56,7 @@ expected.
 The cgroup freezer is hierarchical. Freezing a cgroup freezes all
 tasks belonging to the cgroup and all its descendant cgroups. Each
 cgroup has its own state (self-state) and the state inherited from the
-parent (parent-state). Iff both states are THAWED, the cgroup is
+parent (parent-state). If both states are THAWED, the cgroup is
 THAWED.
 
 The following cgroupfs files are created by cgroup freezer.
@@ -87,7 +87,7 @@ The following cgroupfs files are created by cgroup freezer.
 * freezer.self_freezing: Read only.
 
   Shows the self-state. 0 if the self-state is THAWED; otherwise, 1.
-  This value is 1 iff the last write to freezer.state was "FROZEN".
+  This value is 1 if the last write to freezer.state was "FROZEN".
 
 * freezer.parent_freezing: Read only.
 
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index de2c432dee20..71d2b46d1968 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -120,7 +120,7 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
 		goto out_err;
 
 	/*
-	 * Migrate tasks one-by-one until @from is empty.  This fails iff
+	 * Migrate tasks one-by-one until @from is empty.  This fails if
 	 * ->can_attach() fails.
 	 */
 	do {
@@ -215,7 +215,7 @@ static void cgroup_pidlist_destroy_work_fn(struct work_struct *work)
 	mutex_lock(&l->owner->pidlist_mutex);
 
 	/*
-	 * Destroy iff we didn't get queued again.  The state won't change
+	 * Destroy if we didn't get queued again.  The state won't change
 	 * as destroy_dwork can only be queued while locked.
 	 */
 	if (!delayed_work_pending(dwork)) {
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 3a0161c21b6b..b831554372a2 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -793,7 +793,7 @@ static bool css_set_populated(struct css_set *cset)
  * One of the css_sets associated with @cgrp is either getting its first
  * task or losing the last.  Update @cgrp->nr_populated_* accordingly.  The
  * count is propagated towards root so that a given cgroup's
- * nr_populated_children is zero iff none of its descendants contain any
+ * nr_populated_children is zero if none of its descendants contain any
  * tasks.
  *
  * @cgrp's interface file "cgroup.populated" is zero if both
@@ -2410,7 +2410,7 @@ struct task_struct *cgroup_taskset_next(struct cgroup_taskset *tset,
  * @mgctx: migration context
  *
  * Migrate tasks in @mgctx as setup by migration preparation functions.
- * This function fails iff one of the ->can_attach callbacks fails and
+ * This function fails if one of the ->can_attach callbacks fails and
  * guarantees that either all or none of the tasks in @mgctx are migrated.
  * @mgctx is consumed regardless of success.
  */
@@ -4264,7 +4264,7 @@ struct cgroup_subsys_state *css_next_child(struct cgroup_subsys_state *pos,
 	 * increasing unique serial number and always appended to the
 	 * sibling list, the next one can be found by walking the parent's
 	 * children until the first css with higher serial number than
-	 * @pos's.  While this path can be slower, it happens iff iteration
+	 * @pos's.  While this path can be slower, it happens if iteration
 	 * races against release and the race window is very small.
 	 */
 	if (!pos) {
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index adb5190c4429..f09fc0347550 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -782,7 +782,7 @@ static int generate_sched_domains(cpumask_var_t **domains,
 		if (cp == &top_cpuset)
 			continue;
 		/*
-		 * Continue traversing beyond @cp iff @cp has some CPUs and
+		 * Continue traversing beyond @cp if @cp has some CPUs and
 		 * isn't load balancing.  The former is obvious.  The
 		 * latter: All child cpusets contain a subset of the
 		 * parent's cpus, so just skip them, and then we call
@@ -1801,7 +1801,7 @@ static int update_nodemask(struct cpuset *cs, struct cpuset *trialcs,
 	}
 
 	/*
-	 * An empty mems_allowed is ok iff there are no tasks in the cpuset.
+	 * An empty mems_allowed is ok if there are no tasks in the cpuset.
 	 * Since nodelist_parse() fails on an empty mask, we special case
 	 * that parsing.  The validate_change() call ensures that cpusets
 	 * with tasks have memory.
-- 
2.25.1

Re: [PATCH] cgroup: Fix typo in comments and documents

From: Hu Haowen <hidden>
Date: 2021-07-30 13:43:58

在 2021/7/30 下午1:16, Cai Huoqing 写道:
Fix typo: iff  ==> if

Signed-off-by: Cai Huoqing <redacted>

Reviewed-by: Hu Haowen <redacted>

quoted hunk
---
 Documentation/admin-guide/cgroup-v1/cgroups.rst           | 2 +-
 Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst | 4 ++--
 kernel/cgroup/cgroup-v1.c                                 | 4 ++--
 kernel/cgroup/cgroup.c                                    | 6 +++---
 kernel/cgroup/cpuset.c                                    | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v1/cgroups.rst b/Documentation/admin-guide/cgroup-v1/cgroups.rst
index b0688011ed06..fa747466e304 100644
--- a/Documentation/admin-guide/cgroup-v1/cgroups.rst
+++ b/Documentation/admin-guide/cgroup-v1/cgroups.rst
@@ -573,7 +573,7 @@ cgroup_for_each_descendant_pre() for details.
 ``void css_offline(struct cgroup *cgrp);``
 (cgroup_mutex held by caller)
 
-This is the counterpart of css_online() and called iff css_online()
+This is the counterpart of css_online() and called if css_online()
 has succeeded on @cgrp. This signifies the beginning of the end of
 @cgrp. @cgrp is being removed and the subsystem should start dropping
 all references it's holding on @cgrp. When all references are dropped,
diff --git a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
index 582d3427de3f..a908c5226bde 100644
--- a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
+++ b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
@@ -56,7 +56,7 @@ expected.
 The cgroup freezer is hierarchical. Freezing a cgroup freezes all
 tasks belonging to the cgroup and all its descendant cgroups. Each
 cgroup has its own state (self-state) and the state inherited from the
-parent (parent-state). Iff both states are THAWED, the cgroup is
+parent (parent-state). If both states are THAWED, the cgroup is
 THAWED.
 
 The following cgroupfs files are created by cgroup freezer.
@@ -87,7 +87,7 @@ The following cgroupfs files are created by cgroup freezer.
 * freezer.self_freezing: Read only.
 
   Shows the self-state. 0 if the self-state is THAWED; otherwise, 1.
-  This value is 1 iff the last write to freezer.state was "FROZEN".
+  This value is 1 if the last write to freezer.state was "FROZEN".
 
 * freezer.parent_freezing: Read only.
 
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index de2c432dee20..71d2b46d1968 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -120,7 +120,7 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
 		goto out_err;
 
 	/*
-	 * Migrate tasks one-by-one until @from is empty.  This fails iff
+	 * Migrate tasks one-by-one until @from is empty.  This fails if
 	 * ->can_attach() fails.
 	 */
 	do {
@@ -215,7 +215,7 @@ static void cgroup_pidlist_destroy_work_fn(struct work_struct *work)
 	mutex_lock(&l->owner->pidlist_mutex);
 
 	/*
-	 * Destroy iff we didn't get queued again.  The state won't change
+	 * Destroy if we didn't get queued again.  The state won't change
 	 * as destroy_dwork can only be queued while locked.
 	 */
 	if (!delayed_work_pending(dwork)) {
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 3a0161c21b6b..b831554372a2 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -793,7 +793,7 @@ static bool css_set_populated(struct css_set *cset)
  * One of the css_sets associated with @cgrp is either getting its first
  * task or losing the last.  Update @cgrp->nr_populated_* accordingly.  The
  * count is propagated towards root so that a given cgroup's
- * nr_populated_children is zero iff none of its descendants contain any
+ * nr_populated_children is zero if none of its descendants contain any
  * tasks.
  *
  * @cgrp's interface file "cgroup.populated" is zero if both
@@ -2410,7 +2410,7 @@ struct task_struct *cgroup_taskset_next(struct cgroup_taskset *tset,
  * @mgctx: migration context
  *
  * Migrate tasks in @mgctx as setup by migration preparation functions.
- * This function fails iff one of the ->can_attach callbacks fails and
+ * This function fails if one of the ->can_attach callbacks fails and
  * guarantees that either all or none of the tasks in @mgctx are migrated.
  * @mgctx is consumed regardless of success.
  */
@@ -4264,7 +4264,7 @@ struct cgroup_subsys_state *css_next_child(struct cgroup_subsys_state *pos,
 	 * increasing unique serial number and always appended to the
 	 * sibling list, the next one can be found by walking the parent's
 	 * children until the first css with higher serial number than
-	 * @pos's.  While this path can be slower, it happens iff iteration
+	 * @pos's.  While this path can be slower, it happens if iteration
 	 * races against release and the race window is very small.
 	 */
 	if (!pos) {
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index adb5190c4429..f09fc0347550 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -782,7 +782,7 @@ static int generate_sched_domains(cpumask_var_t **domains,
 		if (cp == &top_cpuset)
 			continue;
 		/*
-		 * Continue traversing beyond @cp iff @cp has some CPUs and
+		 * Continue traversing beyond @cp if @cp has some CPUs and
 		 * isn't load balancing.  The former is obvious.  The
 		 * latter: All child cpusets contain a subset of the
 		 * parent's cpus, so just skip them, and then we call
@@ -1801,7 +1801,7 @@ static int update_nodemask(struct cpuset *cs, struct cpuset *trialcs,
 	}
 
 	/*
-	 * An empty mems_allowed is ok iff there are no tasks in the cpuset.
+	 * An empty mems_allowed is ok if there are no tasks in the cpuset.
 	 * Since nodelist_parse() fails on an empty mask, we special case
 	 * that parsing.  The validate_change() call ensures that cpusets
 	 * with tasks have memory.

Re: [PATCH] cgroup: Fix typo in comments and documents

From: Hu Haowen <hidden>
Date: 2021-07-30 13:44:32

在 2021/7/30 下午1:16, Cai Huoqing 写道:
Fix typo: iff  ==> if

Signed-off-by: Cai Huoqing <redacted>

Reviewed-by: Hu Haowen <redacted>

quoted hunk
---
 Documentation/admin-guide/cgroup-v1/cgroups.rst           | 2 +-
 Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst | 4 ++--
 kernel/cgroup/cgroup-v1.c                                 | 4 ++--
 kernel/cgroup/cgroup.c                                    | 6 +++---
 kernel/cgroup/cpuset.c                                    | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v1/cgroups.rst b/Documentation/admin-guide/cgroup-v1/cgroups.rst
index b0688011ed06..fa747466e304 100644
--- a/Documentation/admin-guide/cgroup-v1/cgroups.rst
+++ b/Documentation/admin-guide/cgroup-v1/cgroups.rst
@@ -573,7 +573,7 @@ cgroup_for_each_descendant_pre() for details.
 ``void css_offline(struct cgroup *cgrp);``
 (cgroup_mutex held by caller)
 
-This is the counterpart of css_online() and called iff css_online()
+This is the counterpart of css_online() and called if css_online()
 has succeeded on @cgrp. This signifies the beginning of the end of
 @cgrp. @cgrp is being removed and the subsystem should start dropping
 all references it's holding on @cgrp. When all references are dropped,
diff --git a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
index 582d3427de3f..a908c5226bde 100644
--- a/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
+++ b/Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst
@@ -56,7 +56,7 @@ expected.
 The cgroup freezer is hierarchical. Freezing a cgroup freezes all
 tasks belonging to the cgroup and all its descendant cgroups. Each
 cgroup has its own state (self-state) and the state inherited from the
-parent (parent-state). Iff both states are THAWED, the cgroup is
+parent (parent-state). If both states are THAWED, the cgroup is
 THAWED.
 
 The following cgroupfs files are created by cgroup freezer.
@@ -87,7 +87,7 @@ The following cgroupfs files are created by cgroup freezer.
 * freezer.self_freezing: Read only.
 
   Shows the self-state. 0 if the self-state is THAWED; otherwise, 1.
-  This value is 1 iff the last write to freezer.state was "FROZEN".
+  This value is 1 if the last write to freezer.state was "FROZEN".
 
 * freezer.parent_freezing: Read only.
 
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index de2c432dee20..71d2b46d1968 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -120,7 +120,7 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from)
 		goto out_err;
 
 	/*
-	 * Migrate tasks one-by-one until @from is empty.  This fails iff
+	 * Migrate tasks one-by-one until @from is empty.  This fails if
 	 * ->can_attach() fails.
 	 */
 	do {
@@ -215,7 +215,7 @@ static void cgroup_pidlist_destroy_work_fn(struct work_struct *work)
 	mutex_lock(&l->owner->pidlist_mutex);
 
 	/*
-	 * Destroy iff we didn't get queued again.  The state won't change
+	 * Destroy if we didn't get queued again.  The state won't change
 	 * as destroy_dwork can only be queued while locked.
 	 */
 	if (!delayed_work_pending(dwork)) {
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 3a0161c21b6b..b831554372a2 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -793,7 +793,7 @@ static bool css_set_populated(struct css_set *cset)
  * One of the css_sets associated with @cgrp is either getting its first
  * task or losing the last.  Update @cgrp->nr_populated_* accordingly.  The
  * count is propagated towards root so that a given cgroup's
- * nr_populated_children is zero iff none of its descendants contain any
+ * nr_populated_children is zero if none of its descendants contain any
  * tasks.
  *
  * @cgrp's interface file "cgroup.populated" is zero if both
@@ -2410,7 +2410,7 @@ struct task_struct *cgroup_taskset_next(struct cgroup_taskset *tset,
  * @mgctx: migration context
  *
  * Migrate tasks in @mgctx as setup by migration preparation functions.
- * This function fails iff one of the ->can_attach callbacks fails and
+ * This function fails if one of the ->can_attach callbacks fails and
  * guarantees that either all or none of the tasks in @mgctx are migrated.
  * @mgctx is consumed regardless of success.
  */
@@ -4264,7 +4264,7 @@ struct cgroup_subsys_state *css_next_child(struct cgroup_subsys_state *pos,
 	 * increasing unique serial number and always appended to the
 	 * sibling list, the next one can be found by walking the parent's
 	 * children until the first css with higher serial number than
-	 * @pos's.  While this path can be slower, it happens iff iteration
+	 * @pos's.  While this path can be slower, it happens if iteration
 	 * races against release and the race window is very small.
 	 */
 	if (!pos) {
diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index adb5190c4429..f09fc0347550 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -782,7 +782,7 @@ static int generate_sched_domains(cpumask_var_t **domains,
 		if (cp == &top_cpuset)
 			continue;
 		/*
-		 * Continue traversing beyond @cp iff @cp has some CPUs and
+		 * Continue traversing beyond @cp if @cp has some CPUs and
 		 * isn't load balancing.  The former is obvious.  The
 		 * latter: All child cpusets contain a subset of the
 		 * parent's cpus, so just skip them, and then we call
@@ -1801,7 +1801,7 @@ static int update_nodemask(struct cpuset *cs, struct cpuset *trialcs,
 	}
 
 	/*
-	 * An empty mems_allowed is ok iff there are no tasks in the cpuset.
+	 * An empty mems_allowed is ok if there are no tasks in the cpuset.
 	 * Since nodelist_parse() fails on an empty mask, we special case
 	 * that parsing.  The validate_change() call ensures that cpusets
 	 * with tasks have memory.

Re: [PATCH] cgroup: Fix typo in comments and documents

From: Jonathan Corbet <corbet@lwn.net>
Date: 2021-07-30 14:51:33

Cai Huoqing [off-list ref] writes:
Fix typo: iff  ==> if

Signed-off-by: Cai Huoqing <redacted>
This is becoming an FAQ ...  "iff" in mathematical English means "if and
only if"; its usage in these documents is correct.

Thanks,

jon

Re: [PATCH] cgroup: Fix typo in comments and documents

From: Shakeel Butt <hidden>
Date: 2021-07-30 14:53:24

On Fri, Jul 30, 2021 at 6:44 AM Hu Haowen [off-list ref] wrote:

在 2021/7/30 下午1:16, Cai Huoqing 写道:
quoted
Fix typo: iff  ==> if
This is not a typo. 'iff' means 'if and only if'. For details see
https://en.wikipedia.org/wiki/If_and_only_if.

RE: [PATCH] cgroup: Fix typo in comments and documents

From: Cai,Huoqing <hidden>
Date: 2021-07-30 14:55:14

Forget it - -

-----Original Message-----
From: Shakeel Butt <redacted> 
Sent: 2021年7月30日 22:53
To: Hu Haowen <redacted>
Cc: Cai,Huoqing <redacted>; Tejun Heo <tj@kernel.org>; Zefan Li <redacted>; Johannes Weiner <hannes@cmpxchg.org>; Jonathan Corbet <corbet@lwn.net>; Cgroups <redacted>; linux-doc@vger.kernel.org; LKML <redacted>
Subject: Re: [PATCH] cgroup: Fix typo in comments and documents

On Fri, Jul 30, 2021 at 6:44 AM Hu Haowen [off-list ref] wrote:

在 2021/7/30 下午1:16, Cai Huoqing 写道:
quoted
Fix typo: iff  ==> if
This is not a typo. 'iff' means 'if and only if'. For details see https://en.wikipedia.org/wiki/If_and_only_if.

Re: [PATCH] cgroup: Fix typo in comments and documents

From: Matthew Wilcox <willy@infradead.org>
Date: 2021-07-30 15:04:50

On Fri, Jul 30, 2021 at 08:51:29AM -0600, Jonathan Corbet wrote:
Cai Huoqing [off-list ref] writes:
quoted
Fix typo: iff  ==> if

Signed-off-by: Cai Huoqing <redacted>
This is becoming an FAQ ...  "iff" in mathematical English means "if and
only if"; its usage in these documents is correct.
... and yet it's clearly not understood.  Similarly to the [start..end)
convention (also the [start..end[ convention).  Should we deprecate
use of it in kernel documentation, and if so, what should we replace it
with?

Re: [PATCH] cgroup: Fix typo in comments and documents

From: Hu Haowen <hidden>
Date: 2021-07-30 16:07:29

在 2021/7/30 下午10:54, Cai,Huoqing 写道:
Forget it - -

-----Original Message-----
From: Shakeel Butt <redacted> 
Sent: 2021年7月30日 22:53
To: Hu Haowen <redacted>
Cc: Cai,Huoqing <redacted>; Tejun Heo <tj@kernel.org>; Zefan Li <redacted>; Johannes Weiner <hannes@cmpxchg.org>; Jonathan Corbet <corbet@lwn.net>; Cgroups <redacted>; linux-doc@vger.kernel.org; LKML <redacted>
Subject: Re: [PATCH] cgroup: Fix typo in comments and documents

On Fri, Jul 30, 2021 at 6:44 AM Hu Haowen [off-list ref] wrote:
quoted
在 2021/7/30 下午1:16, Cai Huoqing 写道:
quoted
Fix typo: iff  ==> if
This is not a typo. 'iff' means 'if and only if'. For details see https://en.wikipedia.org/wiki/If_and_only_if.

Sorry, my mistake.


Thx,

Hu Haowen

Re: [PATCH] cgroup: Fix typo in comments and documents

From: Jonathan Corbet <corbet@lwn.net>
Date: 2021-07-30 19:16:48

Matthew Wilcox [off-list ref] writes:
On Fri, Jul 30, 2021 at 08:51:29AM -0600, Jonathan Corbet wrote:
quoted
Cai Huoqing [off-list ref] writes:
quoted
Fix typo: iff  ==> if

Signed-off-by: Cai Huoqing <redacted>
This is becoming an FAQ ...  "iff" in mathematical English means "if and
only if"; its usage in these documents is correct.
... and yet it's clearly not understood.  Similarly to the [start..end)
convention (also the [start..end[ convention).  Should we deprecate
use of it in kernel documentation, and if so, what should we replace it
with?
I'm never quite sure what to do with these things...we want to be
inclusive, but we don't want to hobble the language we use beyond a
certain point.  We could ask people to spell out "if and only if", I
suppose, but that sounds like the kind of thing that leads to unpleasant
messages in my inbox.

Thanks,

jon

Re: [PATCH] cgroup: Fix typo in comments and documents

From: Hu Haowen <hidden>
Date: 2021-08-01 03:39:34

在 2021/7/30 下午11:03, Matthew Wilcox 写道:
On Fri, Jul 30, 2021 at 08:51:29AM -0600, Jonathan Corbet wrote:
quoted
Cai Huoqing [off-list ref] writes:
quoted
Fix typo: iff  ==> if

Signed-off-by: Cai Huoqing <redacted>
This is becoming an FAQ ...  "iff" in mathematical English means "if and
only if"; its usage in these documents is correct.
... and yet it's clearly not understood.  Similarly to the [start..end)
convention (also the [start..end[ convention).  Should we deprecate
use of it in kernel documentation, and if so, what should we replace it
with?
What about establishing a documentation section which gives clear
definitions to each words whose meaning isn't easy to understand for
common people, such as this situation? In this case readers are able to
get rid of their questions on their own, instead of asking maintainers
for any explanation.

Regards,
Hu Haowen
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help