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.
