On Tue, Aug 24, 2021 at 08:23:15PM +0100, Matthew Wilcox wrote:
> > So when you mention "slab" as a name example, that's not the argument
> > you think it is. That's a real honest-to-goodness operating system
> > convention name that doesn't exactly predate Linux, but is most
> > certainly not new.
>
> Sure, but at the time Jeff Bonwick chose it, it had no meaning in
> computer science or operating system design.
I think the big difference is that "slab" is mostly used as an
internal name. In Linux it doesn't even leak out to the users, since
we use kmem_cache_{create,alloc,free,destroy}(). So the "slab"
doesn't even show up in the API.
The problem is whether we use struct head_page, or folio, or mempages,
we're going to be subsystem users' faces. And people who are using it
every day will eventually get used to anything, whether it's "folio"
or "xmoqax", we sould give a thought to newcomers to Linux file system
code. If they see things like "read_folio()", they are going to be
far more confused than "read_pages()" or "read_mempages()".
Sure, one impenetrable code word isn't that bad. But this is a case
of a death by a thousand cuts. At $WORK, one time we had welcomed an
intern to our group, I had to stop everyone each time that they used
an acronym, or a codeword, and asked them to define the term.
It was really illuminating what an insider takes for granted, but when
it's one cutsy codeword after another, with three or more such
codewords in a sentence, it's *really* a less-than-great initial
experience for a newcomer.
So if someone sees "kmem_cache_alloc()", they can probably make a
guess what it means, and it's memorable once they learn it.
Similarly, something like "head_page", or "mempages" is going to a bit
more obvious to a kernel newbie. So if we can make a tiny gesture
towards comprehensibility, it would be good to do so while it's still
easier to change the name.
Cheers,
- Ted
