The glibc test suite contains a few tiny FUSE file systems. For example, there is one that just happens to contain every file that mkstemp attempts to create, for a test that exercises the O_CREAT|O_EXCL failure path. Like the Rust fuser crate, it uses the kernel API directly. The tests are slightly brittle because sometimes we encounter a new LSM that triggers unexpected file system operations, but it's not too bad overall.
What I found funny when I discovered it is that you can create a thread in the same process that provides the FUSE file system implementation for this very process. It makes it much easier to write certain tests, especially debugging. We had to teach valgrind that more system calls effectively perform callbacks into the same process, but fortunately valgrind already had a FUSE_COMPATIBLE_MAY_BLOCK mechanism for that.
Indeed, the glibc test suite .. plus a suite of BPF scripts for instrumenting .. can provide a great deal of information about how things are running in a target OS .. if you give a process its own filesystem and then rig up a bpf console with some hot gnuplot, you can get some very significant details, at the i/o level, about the heuristics of an application, library, user-space module/plugin, etc...
It used to be you had to wade through massive logs though, if you don't get things quite tweaked - but in the AI/ML agent sense of things these days, just describe what you need, FUSE the right nodes, and run the bpf scripts, yo ..
I agree with you, I also enjoy reading it, and admire the method as well as the result in this case.
FUSE is immensely useful, also. Its the front-/back- door to a lot of things. There's only a few steps left to a tiny crypto-stack, hosted on top of it ..
The glibc test suite contains a few tiny FUSE file systems. For example, there is one that just happens to contain every file that mkstemp attempts to create, for a test that exercises the O_CREAT|O_EXCL failure path. Like the Rust fuser crate, it uses the kernel API directly. The tests are slightly brittle because sometimes we encounter a new LSM that triggers unexpected file system operations, but it's not too bad overall.
What I found funny when I discovered it is that you can create a thread in the same process that provides the FUSE file system implementation for this very process. It makes it much easier to write certain tests, especially debugging. We had to teach valgrind that more system calls effectively perform callbacks into the same process, but fortunately valgrind already had a FUSE_COMPATIBLE_MAY_BLOCK mechanism for that.
Indeed, the glibc test suite .. plus a suite of BPF scripts for instrumenting .. can provide a great deal of information about how things are running in a target OS .. if you give a process its own filesystem and then rig up a bpf console with some hot gnuplot, you can get some very significant details, at the i/o level, about the heuristics of an application, library, user-space module/plugin, etc...
It used to be you had to wade through massive logs though, if you don't get things quite tweaked - but in the AI/ML agent sense of things these days, just describe what you need, FUSE the right nodes, and run the bpf scripts, yo ..
The older I get, the more I appreciate posts that are basically I wanted to understand X, so I built a tiny version of it.
I don't know why, but I really enjoy reading this kind of content. I admire the people who implement and maintain this system.
I agree with you, I also enjoy reading it, and admire the method as well as the result in this case.
FUSE is immensely useful, also. Its the front-/back- door to a lot of things. There's only a few steps left to a tiny crypto-stack, hosted on top of it ..
I had saved this kind of content, but I hadn't shared it here; maybe it will catch the attention of others like us. but it looks I could not find it
Kernel FUSE documentation is a dead link
https://www.kernel.org/doc/html/next/filesystems/fuse.html
Can someone tell me if this is LLM generated content or not? I tried to look for obvious signs but didn't notice anything.
If I have to ask whether something is AI-generated after reading 11 minutes of filesystem internals, that's probably a compliment to the writing.
Looks human written to me. But if nothing stands out, then why care?
No, your comment is not LLM generated. Or, at least, I hope it isn't.
Why?