chris@FreeBSD.org
Copyright © 2000 by Chris M. Costello
September 2000
The File Descriptor table file system (fdescfs) has been my project for the past couple of months, off and on. I've recently gotten around to updating this file system to make it cleaner, with the intent of including it into the devfs project.
DTYPE macros are used to differentiate between different types in the file descriptor table. There are currently five such macros--DTYPE_VNODE, DTYPE_SOCKET, DTYPE_PIPE, DTYPE_FIFO, and DTYPE_KQUEUE. There are two very large problems with this technique:
To add any new file type to the system, for example, for the kqueue mechanism, fdescfs and other code using DTYPE macros to report a file table need to be modified and recompiled.
Should any driver register itself a new file type (by means of a new fileops entry), fdescfs would probably report inaccurate information for it, if not just plain garbage.
The solution to the inflexibility of the DTYPE macros is to not use them at all, but instead to rely on the fileops functions.
In fdescfs, the setattr VOP is only permitted for files that are backed by a vnode--FIFOs and regular files. This would mean that there would need to be some way of identifying a vnode other than by file type. This was solved using the getvnode() function, which currently only checks DTYPE_VNODE and DTYPE_FIFO, but could be changed to check for an identifier in a struct file telling whether something is a vnode. In any case, this is left to getvnode(), which will be a lot easier to change.
One more issue this patch touches on is the usage of curproc where there isn't really need for it. The fdesc_allocvp() function has been modified to be passed a struct proc pointer to the calling process.
Currently I don't know exactly how to tell whether a pipe can be written to or read from. A patch to sys/kern/sys_pipe.c:pipe_stat() would be much appreciated.