linux-kernel - Re: [GIT PULL] first round of SCSI updates for the 6.4+ merge window

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]

Message-ID: <CAHk-=whkqWU+OVkU5YM=X0rdF4wvcMynReCo+0fyD8ErMb51Sg@mail.gmail.com>
Date:   Mon, 3 Jul 2023 10:25:14 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Mike Christie <michael.christie@...cle.com>
Cc:     James Bottomley <James.Bottomley@...senpartnership.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-scsi <linux-scsi@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>
Subject: Re: [GIT PULL] first round of SCSI updates for the 6.4+ merge window

On Mon, 3 Jul 2023 at 10:09, Mike Christie <michael.christie@...cle.com> wrote:
>
> Maybe name it persistent_reservation.c, or if people think that's too
> long does persistent_resv.c make sense since we use the "resv"
> abbreviation for reservation in nvme and the block layer.

Yeah, as a non-storage person, I really would prefer more informative names.

Maybe I'll never end up looking at that file again, and my one-time
conflict resolution reaction is really just that, but I do think that
we can afford the extra disk space.

Do people really end up typing that file name so much that the extra
keystrokes would matter (and if so - do you really not use
tab-completion? Is it just me that tab-completes pretty much every
filename I type?)

I did do a simple

    git ls-files | grep '/[a-z][a-z]\.[ch]$'

to see how common this kind of two-letter thing is, and  we do have a
ton of them (the test directory has single-letter "a.c" kind of files
too, but for testing that's fine).

Some of those two-letter things look fine: things like "mm", "fs",
"rw", "rx", "tx", and "io" are I think common enough in kernel
contexts that there is practically no real long-form version of them

And others seem to perhaps make sense within the context of individual
device drivers (ie there seem to be two-letter board revisions).

And then we have the ones that make me just go "Whaa". Like that
"pr.c". If I hadn't looked at it, I would have expected "pr" to be
shorthand for some kind of printing function (eg our "pr_warn()" etc
helpers).

Clearly it's not the only one.

           Linus