Ghosts of Unix Past: a historic search for design patterns

I'd say that the most significant category of objects that don't have file descriptors is the objects that the kernel doesn't manage. There is only limited support for having userspace create structures and then expose them to other programs or other parts of the same program (e.g., from a library to an application) through file descriptors. Of course, programs use a wide variety of objects not managed by the kernel, and many of them could be interacted with primarily through the system calls that use file descriptors. For example, it would be extremely handy in a GUI toolkit to be able to create a dialog box, select() on its file descriptor (along with other sources of input), and then read() the user's response, rather than needing to use callback mechanisms specified by (and particular to) the GUI toolkit. There are also more straightforward examples of cases where userspace provides access to objects which are just like objects that the kernel manages and has file descriptors for, but where the particular objects are not managed by the kernel; for example, the PCM data in a compressed audio file, or everything that Gnome VFS provides beyond the kernel-provided filesystem.