[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgqUNhk8awrnf+WaJQc9henwvXsYTyLbF2UFSL7vCuVyg@mail.gmail.com>
Date: Mon, 18 Nov 2024 11:26:12 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christian Brauner <brauner@...nel.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] vfs tmpfs
On Fri, 15 Nov 2024 at 06:07, Christian Brauner <brauner@...nel.org> 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.
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?
Linus
Powered by blists - more mailing lists