Re: [GIT PULL] vfs tmpfs

From: Christian Brauner
Date: Wed Nov 20 2024 - 03:54:24 EST


On Mon, Nov 18, 2024 at 11:26:12AM -0800, Linus Torvalds wrote:
> On Fri, 15 Nov 2024 at 06:07, Christian Brauner <brauner@xxxxxxxxxx> wrote:
> >
> > This adds case-insensitive support for tmpfs.
>
> Ugh.
>
> I've pulled this, but I don't love it.
>
> This pattern:
>
> if (IS_ENABLED(CONFIG_UNICODE) && IS_CASEFOLDED(dir))
> d_add(dentry, inode);
> else
> d_instantiate(dentry, inode);
>
> needs an explanation, and probably a helper.

I think we had this discussion before where we decided to move all the
checks inline. But yes, this could probably be refactored to be easier
to understand.

>
> And
>
> > include/linux/shmem_fs.h | 6 +-
> > mm/shmem.c | 265 ++++++++++++++++++++++++++++++++++--
>
> I'm starting to think this should be renamed and/or possibly split up
> a bit. The actual path component handling functions should be moved
> out of mm/shmem.c.
>
> The whole "mm/shmem.c" thing made sense back in the days when this was
> mainly about memory management functions with some thing wrappers for
> exposing them as a filesystem, and tmpfs was kind of an odd special
> case.
>
> Those thin wrappers aren't very thin any more, and "shmem" is becoming
> something of a misnomer with the actual filesystem being called
> "tmpfs".
>
> We also actually have *two* different implementations of "tmpfs" -
> both in that same file - which is really annoying. The other one is
> based on the ramfs code.
>
> Would it be possible to try to make this a bit saner?

So one possibility would be to move tmpfs into fs and have fs/tmpfs/ (or
mm/tmpfs/) which would also be nice because mm/shmem.c is actively
confusing when you're looking for the tmpfs code. And then it could
simply be split up. I'm all for it.