Understanding OSX Fuse driver flow.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Understanding OSX Fuse driver flow.

Irad K
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 daemon)

            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 fdisp_wait_answ) 
once the read has been completed and response has returned ? 

thanks, 
Irad

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Understanding OSX Fuse driver flow.

Nikolaus Rath
On Jun 22 2017, Irad K <[hidden email]> wrote:
> 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.

Best,
-Nikolaus

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

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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel
Loading...