Re: [PATCH v2] docs: Fix typo in comment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






At 2022-07-21 10:49:40, "Baoquan He" <bhe@xxxxxxxxxx> wrote:
>On 07/21/22 at 09:56am, Slark Xiao wrote:
>> Fix typo in the comment
>
>Better tell what's fixed to save reviewers' time:
>
>Fix typo 'the the' in several places of document.
>
>Other then this nitpick, looks good to me.
>
>Reviewed-by: Baoquan He <bhe@xxxxxxxxxx>
>
Thanks for your advice.
I will update it to  other commits later.

>> 
>> Signed-off-by: Slark Xiao <slark_xiao@xxxxxxx>
>> ---
>> v2: Add all .rst changes in Documents into 1 single patch
>> ---
>>  Documentation/admin-guide/kdump/vmcoreinfo.rst    | 2 +-
>>  Documentation/bpf/map_cgroup_storage.rst          | 4 ++--
>>  Documentation/core-api/cpu_hotplug.rst            | 2 +-
>>  Documentation/driver-api/isa.rst                  | 2 +-
>>  Documentation/filesystems/caching/backend-api.rst | 2 +-
>>  Documentation/locking/seqlock.rst                 | 2 +-
>>  Documentation/sphinx/cdomain.py                   | 2 +-
>>  7 files changed, 8 insertions(+), 8 deletions(-)
>> 
>> diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
>> index 8419019b6a88..6726f439958c 100644
>> --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
>> +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
>> @@ -200,7 +200,7 @@ prb
>>  
>>  A pointer to the printk ringbuffer (struct printk_ringbuffer). This
>>  may be pointing to the static boot ringbuffer or the dynamically
>> -allocated ringbuffer, depending on when the the core dump occurred.
>> +allocated ringbuffer, depending on when the core dump occurred.
>>  Used by user-space tools to read the active kernel log buffer.
>>  
>>  printk_rb_static
>> diff --git a/Documentation/bpf/map_cgroup_storage.rst b/Documentation/bpf/map_cgroup_storage.rst
>> index cab9543017bf..8e5fe532c07e 100644
>> --- a/Documentation/bpf/map_cgroup_storage.rst
>> +++ b/Documentation/bpf/map_cgroup_storage.rst
>> @@ -31,7 +31,7 @@ The map uses key of type of either ``__u64 cgroup_inode_id`` or
>>      };
>>  
>>  ``cgroup_inode_id`` is the inode id of the cgroup directory.
>> -``attach_type`` is the the program's attach type.
>> +``attach_type`` is the program's attach type.
>>  
>>  Linux 5.9 added support for type ``__u64 cgroup_inode_id`` as the key type.
>>  When this key type is used, then all attach types of the particular cgroup and
>> @@ -155,7 +155,7 @@ However, the BPF program can still only associate with one map of each type
>>  ``BPF_MAP_TYPE_CGROUP_STORAGE`` or more than one
>>  ``BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE``.
>>  
>> -In all versions, userspace may use the the attach parameters of cgroup and
>> +In all versions, userspace may use the attach parameters of cgroup and
>>  attach type pair in ``struct bpf_cgroup_storage_key`` as the key to the BPF map
>>  APIs to read or update the storage for a given attachment. For Linux 5.9
>>  attach type shared storages, only the first value in the struct, cgroup inode
>> diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst
>> index c6f4ba2fb32d..f75778d37488 100644
>> --- a/Documentation/core-api/cpu_hotplug.rst
>> +++ b/Documentation/core-api/cpu_hotplug.rst
>> @@ -560,7 +560,7 @@ available:
>>    * cpuhp_state_remove_instance(state, node)
>>    * cpuhp_state_remove_instance_nocalls(state, node)
>>  
>> -The arguments are the same as for the the cpuhp_state_add_instance*()
>> +The arguments are the same as for the cpuhp_state_add_instance*()
>>  variants above.
>>  
>>  The functions differ in the way how the installed callbacks are treated:
>> diff --git a/Documentation/driver-api/isa.rst b/Documentation/driver-api/isa.rst
>> index def4a7b690b5..3df1b1696524 100644
>> --- a/Documentation/driver-api/isa.rst
>> +++ b/Documentation/driver-api/isa.rst
>> @@ -100,7 +100,7 @@ I believe platform_data is available for this, but if rather not, moving
>>  the isa_driver pointer to the private struct isa_dev is ofcourse fine as
>>  well.
>>  
>> -Then, if the the driver did not provide a .match, it matches. If it did,
>> +Then, if the driver did not provide a .match, it matches. If it did,
>>  the driver match() method is called to determine a match.
>>  
>>  If it did **not** match, dev->platform_data is reset to indicate this to
>> diff --git a/Documentation/filesystems/caching/backend-api.rst b/Documentation/filesystems/caching/backend-api.rst
>> index d7507becf674..3a199fc50828 100644
>> --- a/Documentation/filesystems/caching/backend-api.rst
>> +++ b/Documentation/filesystems/caching/backend-api.rst
>> @@ -122,7 +122,7 @@ volumes, calling::
>>  to tell fscache that a volume has been withdrawn.  This waits for all
>>  outstanding accesses on the volume to complete before returning.
>>  
>> -When the the cache is completely withdrawn, fscache should be notified by
>> +When the cache is completely withdrawn, fscache should be notified by
>>  calling::
>>  
>>  	void fscache_relinquish_cache(struct fscache_cache *cache);
>> diff --git a/Documentation/locking/seqlock.rst b/Documentation/locking/seqlock.rst
>> index 64405e5da63e..bfda1a5fecad 100644
>> --- a/Documentation/locking/seqlock.rst
>> +++ b/Documentation/locking/seqlock.rst
>> @@ -39,7 +39,7 @@ as the writer can invalidate a pointer that the reader is following.
>>  Sequence counters (``seqcount_t``)
>>  ==================================
>>  
>> -This is the the raw counting mechanism, which does not protect against
>> +This is the raw counting mechanism, which does not protect against
>>  multiple writers.  Write side critical sections must thus be serialized
>>  by an external lock.
>>  
>> diff --git a/Documentation/sphinx/cdomain.py b/Documentation/sphinx/cdomain.py
>> index ca8ac9e59ded..a7d1866e72ff 100644
>> --- a/Documentation/sphinx/cdomain.py
>> +++ b/Documentation/sphinx/cdomain.py
>> @@ -151,7 +151,7 @@ class CObject(Base_CObject):
>>      def handle_func_like_macro(self, sig, signode):
>>          u"""Handles signatures of function-like macros.
>>  
>> -        If the objtype is 'function' and the the signature ``sig`` is a
>> +        If the objtype is 'function' and the signature ``sig`` is a
>>          function-like macro, the name of the macro is returned. Otherwise
>>          ``False`` is returned.  """
>>  
>> -- 
>> 2.25.1
>> 
>> 
>> _______________________________________________
>> kexec mailing list
>> kexec@xxxxxxxxxxxxxxxxxxx
>> http://lists.infradead.org/mailman/listinfo/kexec
>> 
--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-cachefs




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]
  Powered by Linux