Using Information in fusd_file_info

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:

• Read-only. The driver can inspect the value, but changing it will have no effect.
  • pid_t pid: The process ID of the process making the request
  • uid_t uid: The user ID of the owner of the process making the request
  • gid_t gid: The group ID of the owner of the process making the request
• Read-write. Any changes to the value will be propagated back to the kernel and be written to the appropriate in-kernel structure.
  • unsigned int flags: A copy of the f_flags field in the kernel's file structure. The flags are an or'd-together set of the kernel's O_ series of flags: O_NONBLOCK, O_APPEND, O_SYNC, etc.
  • void *device_info: The data passed to fusd_register when the device was registered; see Section 5.1 for details
  • void *private_data: A generic per-file-descriptor pointer usable by the driver for its own purposes, such as to keep state (or a pointer to state) that should be maintained between operations on the same instance of an open file. It is guaranteed to be NULL when the file is first opened. See Section 5.2 for more details.
• Hidden fields. The driver should not touch these fields (such as fd). They contain state used by the FUSD library to generate the reply sent to the kernel.

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.