Re: [LSF/MM TOPIC] Making pseudo file systems inodes/dentries more like normal file systems

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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.

It was also only after eventfs had gone around the houses several times
that people suggested kernfs; it wasn't the default answer (why not?).
Plus, if kernfs should have been the default answer early on, why is
there no documentation at all?  I mean fine, eventfs isn't really a new
filesystem, it's an extension of the existing tracefs, which is perhaps
how it sailed under the radar until the initial blow up, but that still
doesn't answer how hostile an environment the VFS currently is to new
coders who don't have six months or more to invest.

James