Comments on: FUSE / CUSE kernel driver dissection notes

By: eli

eli — Wed, 03 Sep 2025 09:29:06 +0000

As the title implies, these are dissection notes: Things I wrote down as I made my way through the kernel code. And indeed, it takes more than a glance…

By: Sachin Hosamani

Sachin Hosamani — Wed, 03 Sep 2025 09:23:02 +0000

Thank you very much, it just felt like you holding my hand and showing the internals.
Just out of curiosity, where all did you get this step-by-step help information from? It is not self informative by looking at source code at a glance.

By: Filip

Filip — Thu, 16 Nov 2023 01:02:30 +0000

Thank you for writing this article! Without it, I don’t know how I’d even get started with CUSE.

One thing I’ve noticed is that max_write + fuse_in_header doesn’t seem to be enough for the read() call buffer any more; While it does work for reading the initial CUSE_INIT request, it fails for FUSE_OPEN afterwards, even though a FUSE_OPEN request isn’t anywhere close to max_write + fuse_in_header bytes long.. I found that I have to add 40 bytes extra to the buffer for the read() for the FUSE_OPEN request to actually succeed. Also, 4096 doesn’t seem to be enough for max_write (read()ing the CUSE_INIT request fails), but going up to 8192 has been enough. It’s probably quite likely that these things have all changed after this article has been written.. Which would have been fine, if any of it was actually documented anywhere else.

By: eli

eli — Wed, 16 Feb 2022 03:16:10 +0000

Yes, it appears in the request header (see “I/O requests” above).

By: Marcos Moraes

Marcos Moraes — Tue, 15 Feb 2022 22:34:39 +0000

Thanks for posting!

Is there a way to get the reader/writer process id ( pid ) from the read/write handlers?
I mean: when running a kernel mode device driver I can get the user space caller process id by :

#include
…
task_pid_nr(current)

I want to known a similar way to that when running a ‘CUSE’ device handler.