The first two callbacks that most drivers typically implement are open and close. Each of these two functions are passed just one argument--the fusd_file_info structure that describes the instance of the file being opened or closed. Use of the information in that structure will be covered in more detail in Section 5.
The semantics of an open callback's return value are exactly the same as inside the kernel:
If an open callback returns 0 (success), a driver is guaranteed to receive exactly one close callback for that file later. By the same token, the close callback will not be called if the open fails. Therefore, open callbacks that can return failure must be sure to deallocate any resources they might have allocated before returning a failure.
Let's return to our example in Program 1, which creates the /dev/hello-world device. If a user types cat /dev/hello-world, cat will will use the open(2) system call to open the file. FUSD will then proxy that system call to the driver and activate the callback that was registered as the open callback. Recall from line 36 of Program 1 that we registered do_open_or_close, which appears on line 8.
In helloworld.c, the open callback always returns 0, or success. However, in a real driver, something more interesting will probably happen--permissions checks, memory allocation for state-keeping, and so forth. The corresponding de-allocation of those resources should occur in the close callback, which is called when a user application calls close on their file descriptor. close callbacks are allowed to return error values, but this does not prevent the file from actually closing.