Re: [fuse-devel] CUSE: Access to user data

[Miklos S. <mi...@sz...>]

Stefan Schönleitner <dev...@gm...> writes:

> Hi,
>
> I'm currently implementing a character device proxy that should tunnel
> all accesses from a 'virtual' CUSE device to a character device on a
> different host over the network.
>
> I based my code on the cusexmp.c example and I'm planning to implement
> network client code to all cuse callbacks (i.e. read/write/ioctl/etc.).
> However, after reading the API documentation and the example code, it is
> not clear to me how user data (i.e. commandline parameters) can be
> accessed from within the read/write/... callback functions.
>
> For instance, in my case, I added "--server" and "--port" parameters to
> the commandline options.
> These parameters are parsed by fuse_opt_parse() and, after that,
> cuse_lowlevel_main() is started.
>
> When I run the code, it should create the specified device file and
> accessing the device (i.e. with a call to open()) should result in a
> callback of the according CUSE callback function that was specified in
> cuse_lowlevel_ops.
>
>
> Thus, in the case of an open(),
> void cuse_open_callback(fuse_req_t req, struct fuse_file_info *fi)
> would be called.
>
> In this function, the commandline parameters for "--server" and "--port"
> should be read and the connection to the server should be established.
> Alternatively, I could already connect to the server in main(), but in
> this case the open callback function would still need the filedescriptor
> of the connected socket.
>
> * How can I access user parameters (i.e. server name and port) from
> inside the callback functions ?
>
> * How can I globally store general information (i.e. the socket
> descriptor that is used to communicate with the server) ?
>
> I'm not really sure how FUSE/CUSE works internally, but I would believe
> that it is multithreaded to allow concurrent accesses to devices.
> In this case, storing everything inside a global variable would cause
> mayhem.
> If there is no other possibility, the obvious solution would be to come
> up with a data structure that uses locking (i.e through pthread locks
> ??) and supports multiple instances ?
>
> * So, what is the recommended method to store information belonging to
> one CUSE instance ?

Store all your private data in a structure passed to the 'userdata'
argument of cuse_lowlevel_main().

Then use fuse_req_userdata() to retrieve the private pointer from the
request.

Thanks,
Miklos