We mentioned in the previous sections that the first argument to every callback is a pointer to a fusd_file_info structure. This structure contains information that can be useful to driver implementers in deciding how to respond to a system call request.
The fields of fusd_file_info structures fall into several categories:
Important note: the value of the fusd_file_info pointer itself has no meaning. Repeated requests on the same file descriptor will not generate callbacks with identical fusd_file_info pointer values, as would be the case with an in-kernel driver. In other words, if a driver needs to keep state in between successive system calls on a user's file descriptor, it must store that state using the private_data field. The fusd_file_info pointer itself is ephemeral; the data to which it points is persistent.
Program 3 shows an example of how a driver might make use of the data in the fusd_file_info structure. Much of the driver is identical to helloworld.c. However, instead of printing a static greeting, this new program generates a custom message each time the device file is read, as seen on line 25. The message contains the PID of the user process that requested the read (file->pid).
In addition, Program 3's open callback does not return 0 (success) unconditionally as it did in Program 1. Instead, it checks (on line 7) to make sure the UID of the process trying to read from the device (file->uid) matches the UID under which the driver itself is running (getuid()). If they don't match, -EPERM is returned. In other words, only the user who ran the driver is allowed to read from the device that it creates. If any other user--including root!--tries to open it, a ``Permission denied'' error will be generated.