Re: [GIT PULL] vfs tmpfs

[Christian Brauner]

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.