Understanding OSX Fuse driver flow.
(too old to reply)
Irad K
2017-06-22 06:14:44 UTC
Hi all,

I wish to learn more about the backend of osx fuse.

I've started with some research about the kernel-user communication by
following the data path in read system call.
The path starting from user-space entity that initiate the action, to the
driver that serve as a path through to user-space filesystem deamon that
perform the action.

As a start, I've focused on read sys call and discovered that this action
is forwarded from vfs layer to *fuse_vnop_read*, with the data kept in '
*uio*' arguments which is the command arguments in user-space (including
buffer for data to be read).

based on these params and other params like the context details, the struct
fuse_dispatcher is created, and this is the entity that eventually being
sent to the deamon more or less ..

here's the fuse_dispatcher class:

struct fuse_dispatcher


struct fuse_ticket *tick;

struct fuse_in_header *finh;

void *indata;

size_t iosize;

uint64_t nodeid;

int answ_stat;

void *answ;


and here's the command that send the dispatcher and wait for response (from

err = fdisp_wait_answ(&fdi);

However, there's some other layer which seem to actually send the data to
user-space, which called *fuse_device_cdevsw* which posses the method
*fuse_device_read. *

Perhaps do you know how is this method connected to the read flow ?

basically what it does is dequeuing the ticket (part of the dispatcher data
we collected in vnop_read), and send it to the deamon. is it working from a
different thread and signal back to vnop_read (in particular
once the read has been completed and response has returned ?

Nikolaus Rath
2017-06-22 18:34:55 UTC
Post by Irad K
Hi all,
I wish to learn more about the backend of osx fuse.

Then the best place to ask is probably the OSXFUSE mailing list. I don't
think we can help you here.

GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

»Time flies like an arrow, fruit flies like a Banana.«