linux-kernel - Re: [PATCH 1/1] block: fix trivial typos in comments

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 29 Mar 2021 12:13:00 -0600
From:   Tom Saeger <tom.saeger@...cle.com>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        rdunlap@...radead.org, Bhaskar Chowdhury <unixbhaskar@...il.com>
Subject: Re: [PATCH 1/1] block: fix trivial typos in comments

On Fri, Mar 26, 2021 at 09:46:36AM -0600, Jens Axboe wrote:
> On 3/26/21 9:45 AM, Tom Saeger wrote:
> > On Fri, Mar 26, 2021 at 09:41:49AM -0600, Jens Axboe wrote:
> >> On 3/25/21 9:04 PM, Tom Saeger wrote:
> >>>
> >>> s/Additonal/Additional/
> >>> s/assocaited/associated/
> >>> s/assocaited/associated/
> >>> s/assocating/associating/
> >>> s/becasue/because/
> >>> s/configred/configured/
> >>> s/deactive/deactivate/
> >>> s/followings/following/
> >>> s/funtion/function/
> >>> s/heirarchy/hierarchy/
> >>> s/intiailized/initialized/
> >>> s/prefered/preferred/
> >>> s/readded/read/
> >>> s/Secion/Section/
> >>> s/soley/solely/
> >>
> >> While I'm generally happy to accept any patch that makes sense, the
> >> recent influx of speling fixes have me less than excited. They just
> >> add complications to backports and stable patches, for example, and
> >> I'd prefer not to take them for that reason alone.
> > 
> > Nod.
> > 
> > In that case - perhaps adding these entries to scripts/spelling.txt
> > would at least catch some going forward?
> > 
> > I can send that.
> 
> That seems like a good idea.
> 
> -- 
> Jens Axboe
> 

What would be the process - which avoids the backport complications?

Perhaps a few of these could be fixed when other changes are made to these files?
Granted these are trivial fixes, just trying to understand the process.

Example work-flow based on recent block merge upstream:

$ git log -n1 abed516ecd02ceb30fbd091e9b26205ea3192c65 --oneline
    abed516ecd02 Merge tag 'block-5.12-2021-03-27' of git://git.kernel.dk/linux-block

# get files changed by recent merge (or use commit range of interest)
$ HID=abed516ecd02 ; git diff --name-only "$(git merge-base "${HID}^2" "${HID}^1")".."${HID}^2"
    block/bio.c
    block/blk-merge.c
    block/partitions/core.c
    fs/block_dev.c

# foreach file in recent merge, run checkpatch in typo fix mode
$ HID=abed516ecd02 ; git diff --name-only "$(git merge-base "${HID}^2" "${HID}^1")".."${HID}^2" \
| xargs ./scripts/checkpatch.pl --strict --fix --fix-inplace --types TYPO_SPELLING -f | grep -A4 -F "CHECK:"
    CHECK: 'splitted' may be misspelled - perhaps 'split'?
    #344: FILE: block/blk-merge.c:344:
    +               /* there isn't chance to merge the splitted bio */
                                                       ^^^^^^^^

    --
    CHECK: 'beeing' may be misspelled - perhaps 'being'?
    #934: FILE: fs/block_dev.c:934:
    + * or NULL if the inode is already beeing freed.
                                        ^^^^^^

# what changed?
$ git status -su
     M block/blk-merge.c
     M fs/block_dev.c


Something similar could be done for other checkpatch modes or other linters.
Just an idea - thoughts?

Regards,

--Tom