Re: [PATCH 0/5] samples/kernfs: Add a pseudo-filesystem to demonstrate kernfs usage

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Jan 28, 2025 at 07:02:24PM -0500, Steven Rostedt wrote:
> On Tue, 28 Jan 2025 13:38:42 -1000
> Tejun Heo <tj@kernel.org> wrote:
> 
> > On Tue, Jan 28, 2025 at 06:29:57PM -0500, Steven Rostedt wrote:
> > > What I did for eventfs, and what I believe kernfs does, is to create a
> > > small descriptor to represent the control data and reference them like what
> > > you would have on disk. That is, the control elements (like an trace event
> > > descriptor) is really what is on "disk". When someone does an "ls" to the
> > > pseudo file system, there needs to be a way for the VFS layer to query the
> > > control structures like how a normal file system would query that data
> > > stored on disk, and then let the VFS layer create the dentry and inodes
> > > when referenced, and more importantly, free them when they are no longer
> > > referenced and there's memory pressure.  
> > 
> > Yeap, that's exactly what kernfs does.
> 
> And eventfs goes one step further. Because there's a full directory layout
> that's identical for every event, it has a single descriptor for directory
> and not for file. As there can be over 10 files per directory/event I
> didn't want to waste even that memory. This is why I couldn't use kernfs
> for eventfs, as I was able to still save a couple of megabytes by not
> having the files have any descriptor representing them (besides a single
> array for all events).

Ok, that's fine, but the original point of "are you sure you want to use
kernfs for anything other than what we have today" remains.  It's only a
limited set of use cases that kernfs is good for, libfs is still the
best place to start out for a virtual filesystem.  The fact that the
majority of our "fake" filesystems are using libfs and not kernfs is
semi-proof of that?

Or is it proof that kernfs is just too undocumented that no one wants to
move to it?  I don't know, but adding samples like this really isn't the
answer to that, the answer would be moving an existing libfs
implementation to use kernfs and then that patch series would be the
example to follow for others.

thanks,

greg k-h