Making procfs Cooler
© Amit Singh. All Rights Reserved. Written in May 2007Background
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.0.0.1:4312 --> 72.14.253.147:20480
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, 10.0.0.1:4568 --> 209.85.139.18:47873
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 Preview.app, 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)
References
Acknowledgments
Thanks to Dan Waylonis, Dave MacLachlan, and Tim Omernick for their help with image processing and sequence grabbing.
Download
The source for procfs can be accessed on the MacFUSE project web site.
You can download a precompiled procfs binary here.