linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Amir Goldstein <amir73il@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, Christian Brauner <brauner@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [LSF/MM TOPIC] Making pseudo file systems inodes/dentries more like normal file systems
Date: Sat, 27 Jan 2024 18:06:37 +0000	[thread overview]
Message-ID: <ZbVGLXu4DuomEvJH@casper.infradead.org> (raw)
In-Reply-To: <d661e4a68a799d8ae85f0eab67b1074bfde6a87b.camel@HansenPartnership.com>

On Sat, Jan 27, 2024 at 09:59:10AM -0500, James Bottomley wrote:
> On Sat, 2024-01-27 at 12:15 +0200, Amir Goldstein wrote:
> > I would like to attend the talk about what happened since we
> > suggested that you use kernfs in LSFMM 2022 and what has happened
> > since. I am being serious, I am not being sarcastic and I am not
> > claiming that you did anything wrong :)
> 
> Actually, could we do the reverse and use this session to investigate
> what's wrong with the VFS for new coders?  I had a somewhat similar
> experience when I did shiftfs way back in 2017.  There's a huge amount
> of VFS knowledge you simply can't pick up reading the VFS API.  The way
> I did it was to look at existing filesystems (for me overlayfs was the
> closes to my use case) as well (and of course configfs which proved to
> be too narrow for the use case).  I'd say it took a good six months
> before I understood the subtleties enough to propose a new filesystem
> and be capable of answering technical questions about it.  And
> remember, like Steve, I'm a fairly competent kernel programmer.  Six
> months plus of code reading is an enormous barrier to place in front of
> anyone wanting to do a simple filesystem, and it would be way bigger if
> that person were new(ish) to Linux.

I'd suggest that eventfs and shiftfs are not "simple filesystems".
They're synthetic filesystems that want to do very different things
from block filesystems and network filesystems.  We have a lot of
infrastructure in place to help authors of, say, bcachefs, but not a lot
of infrastructure for synthetic filesystems (procfs, overlayfs, sysfs,
debugfs, etc).

I don't feel like I have a lot to offer in this area; it's not a
part of the VFS I'm comfortable with.  I don't really understand the
dentry/vfsmount/... interactions.  I'm more focused on the fs/mm/block
interactions.  I would probably also struggle to write a synthetic
filesystem, while I could knock up something that's a clone of ext2 in
a matter of weeks.


  reply	other threads:[~2024-01-27 18:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-25 15:48 [LSF/MM TOPIC] Making pseudo file systems inodes/dentries more like normal file systems Steven Rostedt
2024-01-26  1:24 ` Greg Kroah-Hartman
2024-01-26  1:50   ` Steven Rostedt
2024-01-26  1:59     ` Greg Kroah-Hartman
2024-01-26  2:40       ` Steven Rostedt
2024-01-26 14:16         ` Greg Kroah-Hartman
2024-01-26 15:15           ` Steven Rostedt
2024-01-26 15:41             ` Greg Kroah-Hartman
2024-01-26 16:44               ` Steven Rostedt
2024-01-27 10:15                 ` Amir Goldstein
2024-01-27 14:54                   ` Steven Rostedt
2024-01-27 14:59                   ` James Bottomley
2024-01-27 18:06                     ` Matthew Wilcox [this message]
2024-01-27 19:44                       ` Linus Torvalds
2024-01-27 20:23                         ` James Bottomley
2024-01-29 15:08                         ` Christian Brauner
2024-01-29 15:57                           ` Steven Rostedt
2024-01-27 20:07                       ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZbVGLXu4DuomEvJH@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).