[PATCH] TASK :Linux Kernel Bug Fixing: Fixing Warning/Spelling checks on the rst file

rujra posted 1 patch 9 months ago
Documentation/process/adding-syscalls.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
[PATCH] TASK :Linux Kernel Bug Fixing: Fixing Warning/Spelling checks on the rst file
Posted by rujra 9 months ago
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
Re: [PATCH] TASK :Linux Kernel Bug Fixing: Fixing Warning/Spelling checks on the rst file
Posted by Jonathan Corbet 9 months ago
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