On Tue, 28 Jan 2025 at 07:27, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Mon, 27 Jan 2025 22:08:29 -0800
> Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> >
> > Is that a good idea? kernfs and the interactions with the users of it
> > is a pretty convoluted mess. I'd much prefer people writing their
> > pseudo file systems to the VFS APIs over spreading kernfs usage further.
>
> I have to disagree with this. As someone that uses a pseudo file system to
> interact with my subsystem, I really don't want to have to know the
> intrinsics of the virtual file system layer just so I can interact via the
> file system. Not knowing how to do that properly was what got me in trouble
> with Linus is the first place.
Well, honestly, you were doing some odd things.
For a *simple* filesystem that actually acts as a filesystem, all you
need is in libfs with things like &simple_dir_operations etc.
And we have a *lot* of perfectly regular users of things like that.
Not like the ftrace mess that had very *non*-filesystem semantics with
separate lifetime confusion etc, and that tried to maintain a separate
notion of permissions etc.
To make matters worse, tracefs than had a completely different model
for events, and these interacted oddly in non-filesystem ways.
In other words, all the tracefs problems were self-inflicted, and a
lot of them were because you wanted to go behind the vfs layers back
because you had millions of nodes but didn't want to have millions of
inodes etc.
That's not normal.
I mean, you can pretty much literally look at ramfs:
fs/ramfs/inode.c
and it is a real example filesystem that does a lot of things, but
almost all of it is just using the direct vfs helpers (simple_lookup /
simple_link/ simple_rmdir etc etc). It plays *zero* games with
dentries.
Or look at fs/pstore.
Or any number of other examples.
And no, nobody should *EVER* look at the horror that is tracefs and eventfs.
Linus
