Making procfs Cooler

© Amit Singh. All Rights Reserved. Written in May 2007


I earlier wrote and released as open source a MacFUSE-based process file system (procfs) for Mac OS X. This document describes some new features I added to procfs soon after its first release. The source code for all features discussed here is available.

Process Names

Processes that have "names" (from the standpoint of the Process Manager in Mac OS X) now can be looked up more conveniently. There is a new subdirectory called byname/, which shows named processes as symbolic links to the respective /proc/<pid> directories.

$ ls -F /proc/ 0/ 14577/ 193/ 202/ 223/ 33/ 40/ 51/ 706/ 1/ 152/ 195/ 207/ 228/ 34/ 41/ 54/ 707/ 130/ 156/ 198/ 210/ 23/ 35/ 42/ 59/ 89/ 135/ 161/ 199/ 213/ 27/ 36/ 45/ 61/ byname/ 13928/ 165/ 200/ 216/ 291/ 38/ 46/ 62/ system/ 14293/ 187/ 201/ 219/ 32/ 39/ 47/ 67/ $ ls -F /proc/byname Adium@ Microsoft AU Daemon@ iTunes Helper@ AirPort Disk Agent@ Safari@ loginwindow@ Dock@ SystemUIServer@ procfs@ Finder@ Terminal@ Google Notifier@ UniversalAccessApp@ $ ls -l /proc/byname/Terminal lrwxr-xr-x 1 root wheel 0 Jun 4 15:22 /proc/byname/Terminal -> ../202

Window Information

You can now see information in procfs files about the windows (if any) of a given process. A new subdirectory /proc/<pid>/windows/ contains files with such information. For example, you can see the size and screen coordinates of each window of a process in the onscreen file within this directory.

$ cat /proc/byname/Terminal/windows/onscreen 1 3a 32 x 22 @ (893, 0, 25) 2 44 503 x 364 @ (0, 388, 0) 3 42 503 x 364 @ (-1, 22, 0) 4 118 503 x 364 @ (505, 22, 0) 5 45 503 x 364 @ (503, 389, 0) 6 43 503 x 364 @ (504, 22, 0)

Open File Descriptor Information (x86-Only Feature)

A new file /proc/<pid>/fds now contains information on the file descriptors that are open in the process. For file descriptors that refer to "actual" files, you will see the full pathname to the corresponding file for each descriptor. For descriptors that are TCP sockets, you will see the local and remote address/port information. The output shown below has been trimmed for width.

$ cat /proc/byname/Safari/fds 0 vnode /dev/null 1 vnode /dev/console 2 vnode /dev/console ... 5 POSIX shm 6 vnode /dev/urandom 7 vnode /System/Library/.../A/Resources/Extras2.rsrc 8 vnode /Users/singh/Library/Syndication/Database3 9 socket SOCK_STREAM, tcp, AF_INET, --> 10 socket SOCK_DGRAM, ip, AF_UNIX 11 socket SOCK_DGRAM, ip, AF_UNIX 12 vnode /dev/random 13 socket SOCK_STREAM, tcp, AF_INET, --> 16 vnode /System/Library/.../A/Resources/HIToolbox.rsrc 18 vnode /System/Library/.../English.lproj/Localized.rsrc 23 socket SOCK_DGRAM, ip, AF_UNIX 37 vnode /Library/Internet Plug-Ins/.../Flash Player.rsrc 38 vnode /Library/Internet Plug-Ins/.../Flash Player.rsrc 42 vnode /System/Library/.../A/Resources/QuickTime.rsrc 43 vnode /System/Library/.../English.lproj/Localized.rsrc

The system/ Subdirectory

There is a new subdirectory called system/ that contains further subdirectories such as firmware/ and hardware/.

$ ls -F /proc/system firmware/ hardware/

The file /proc/system/firmware/variables contains a view of the system's firmware variables.

$ cat /proc/system/firmware/variables ... <key>SystemAudioVolume</key> <data> 7g== </data> <key>boot-args</key> <string>-v debug=0x14e kdp_match_name=bogus</string> <key>boot-image</key> <data> ...

The hardware/ subdirectory contains some new subdirectories in addition to those that were present in the previous version of procfs.

$ ls -F /proc/system/hardware camera/ displays/ motionsensor/ cpus/ lightsensor/ mouse/

Display Information

The /proc/system/hardware/displays/ directory contains a subdirectory for each connected display that is online. For example, if you have two displays, you will see subdirectories 0 and 1 within /proc/system/hardware/displays/. The subdirectory for a specific display contains an info file and a screenshot.tiff file.

$ ls -F /proc/system/hardware/displays 0/ 1/ $ ls -F /proc/system/hardware/displays/0 info screenshot.tiff $ cat /proc/system/hardware/displays/0/info resolution 1440x900 base address 0x2018000 bits per pixel 32 bits per sample 8 samples per pixel 3 bytes per row 5888 main display yes builtin display yes OpenGL acceleration yes model number 00009c57 serial number 00000000 unit number 00000000 vendor number 00000610

There are numerous other pieces of information in a running system that you could export through procfs. There's a reason as to why I added files to export the particular information discussed so far: the code to retrieve most of such information was cut-and-pasted from the code I wrote for Mac OS X Internals.

An "Always-Live" Screenshot File

The screenshot.tiff file is especially interesting. The idea is this: the file contains, in TIFF format, a rendering of what's on that display—it's an always-live screenshot! You can simply copy this file to get a screenshot of that display. You copy it again, and you get a new screenshot, and so on. You can even double click on the file within the Finder and the screenshot image will open up "normally".

By default, a procfs volume is marked as "nobrowse" for the Finder. This means that by itself, the Finder will not go into such a volume. procfs does this for technical reasons that we won't go into here. However, for looking at such screenshots, you can instruct the Finder to go into the procfs volume through the Go —> Go to Folder... menu item or the shift-cmd-G key combination.

Picture 1. The screenshot.tiff file in a display subdirectory contains a "live" screenshot of that display

An "Always-Live" Camera File

Along the same lines as an "always-live" display screenshot, we can have a screenshot.tiff file for a camera such as the built-in iSight on many Apple computer models. The /proc/system/hardware/camera/screenshot.tiff file serves that purpose. Every time you open this file, the camera will be briefly activated, a picture will be taken, the camera will be deactivated, and the picture data would be made to look like a TIFF file by procfs. Thus, every time you open this file, you get a new picture—basically what the camera is seeing at that point in time. You could copy the file at some intervals to do some sort of surveillance.

Activating and deactivating the camera has some latency. procfs shoots a picture only when the screenshot.tiff file is opened and it isn't already open. The picture so taken will persist until you close the file (that is, procfs will not shoot a new picture until you close the file). Some applications, such as, may access the file in a manner that increases the amount of time the camera is activated as compared to, say, the case when you simply copy the file instead of opening it in place.

Picture 2. The screenshot.tiff file in the camera contains a "live" picture (what the camera is seeing)



Thanks to Dan Waylonis, Dave MacLachlan, and Tim Omernick for their help with image processing and sequence grabbing.


The source for procfs can be accessed on the MacFUSE project web site.

You can download a precompiled procfs binary here.