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