[GIT PULL] first round of SCSI updates for the 6.4+ merge window

Linus Torvalds torvalds at linux-foundation.org
Mon Jul 3 10:25:14 PDT 2023


On Mon, 3 Jul 2023 at 10:09, Mike Christie <michael.christie at oracle.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



More information about the Linux-nvme mailing list