* [PATCH] TASK :Linux Kernel Bug Fixing: Fixing Warning/Spelling checks on the rst file
@ 2025-05-13 13:48 rujra
2025-05-13 16:34 ` Jonathan Corbet
0 siblings, 1 reply; 2+ messages in thread
From: rujra @ 2025-05-13 13:48 UTC (permalink / raw)
To: skhan, corbet; +Cc: workflows, linux-doc, linux-kernel
TASK : Documentation Task
removed warnings and added "SPDX-License-Identifier: GPL-2.0"
in starting of the file , also instead of using re-use , have used
reuse.
Signed-off-by: Rujra Bhatt <braker.noob.kernel@gmail.com>
<rujrabhatt3@gmail.com>
---
Documentation/process/adding-syscalls.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/adding-syscalls.rst
b/Documentation/process/adding-syscalls.rst
index 906c47f1a9e5..17652610450d 100644
--- a/Documentation/process/adding-syscalls.rst
+++ b/Documentation/process/adding-syscalls.rst
@@ -1,4 +1,4 @@
-
+.. SPDX-License-Identifier: GPL-2.0
.. _addsyscalls:
Adding a New System Call
@@ -117,7 +117,7 @@ then the flags argument should include a value
that is equivalent to setting
the timing window between ``xyzzy()`` and calling
``fcntl(fd, F_SETFD, FD_CLOEXEC)``, where an unexpected ``fork()`` and
``execve()`` in another thread could leak a descriptor to
-the exec'ed program. (However, resist the temptation to re-use the actual value
+the exec'ed program. (However, resist the temptation to reuse the actual value
of the ``O_CLOEXEC`` constant, as it is architecture-specific and is part of a
numbering space of ``O_*`` flags that is fairly full.)
@@ -378,7 +378,7 @@ the compatibility wrapper::
...
555 x32 xyzzy __x32_compat_sys_xyzzy
-If no pointers are involved, then it is preferable to re-use the 64-bit system
+If no pointers are involved, then it is preferable to reuse the 64-bit system
call for the x32 ABI (and consequently the entry in
arch/x86/entry/syscalls/syscall_64.tbl is unchanged).
--
2.43.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] TASK :Linux Kernel Bug Fixing: Fixing Warning/Spelling checks on the rst file
2025-05-13 13:48 [PATCH] TASK :Linux Kernel Bug Fixing: Fixing Warning/Spelling checks on the rst file rujra
@ 2025-05-13 16:34 ` Jonathan Corbet
0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Corbet @ 2025-05-13 16:34 UTC (permalink / raw)
To: rujra, skhan; +Cc: workflows, linux-doc, linux-kernel
Thank you for working to improve our documentation!
A few things...
rujra <braker.noob.kernel@gmail.com> writes:
> TASK : Documentation Task
This line doesn't belong in the changelog.
> removed warnings and added "SPDX-License-Identifier: GPL-2.0"
> in starting of the file , also instead of using re-use , have used
> reuse.
"also" in a changelog suggests you are doing more than one thing, which
is a sign that a patch needs to be broken up.
> Signed-off-by: Rujra Bhatt <braker.noob.kernel@gmail.com>
> <rujrabhatt3@gmail.com>
What's this line?
> ---
> Documentation/process/adding-syscalls.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/process/adding-syscalls.rst
> b/Documentation/process/adding-syscalls.rst
> index 906c47f1a9e5..17652610450d 100644
> --- a/Documentation/process/adding-syscalls.rst
> +++ b/Documentation/process/adding-syscalls.rst
> @@ -1,4 +1,4 @@
> -
> +.. SPDX-License-Identifier: GPL-2.0
We want SPDX lines in our documentation files, but we have to be very
careful about adding them. Do you know that the author of this document
meant to contribute it under that license? They probably did, but it's
not something we can make guesses about.
> .. _addsyscalls:
>
> Adding a New System Call
> @@ -117,7 +117,7 @@ then the flags argument should include a value
> that is equivalent to setting
> the timing window between ``xyzzy()`` and calling
> ``fcntl(fd, F_SETFD, FD_CLOEXEC)``, where an unexpected ``fork()`` and
> ``execve()`` in another thread could leak a descriptor to
> -the exec'ed program. (However, resist the temptation to re-use the actual value
> +the exec'ed program. (However, resist the temptation to reuse the actual value
> of the ``O_CLOEXEC`` constant, as it is architecture-specific and is part of a
As a typo goes, that's pretty minor. When the other stuff is addressed
I can apply this change as a first patch, but would suggest looking for
more substantive problems to solve thereafter.
Thanks,
jon
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-05-13 16:34 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-05-13 13:48 [PATCH] TASK :Linux Kernel Bug Fixing: Fixing Warning/Spelling checks on the rst file rujra
2025-05-13 16:34 ` Jonathan Corbet
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).