alexchandel / procfs Goto Github PK

Homebrew has an awesome repository of FUSE filesystems for OS X on the homebrew/fuse tap.

From the formula guidelines, I think the only change we need is to have our Makefile install the procfs binary and plist to the right Homebrew directory. But that said, our source could use some tidying.

Apple deprecated some useful CG display functions in the 64-bit transition, including CGDisplayBaseAddress() which we use to get a pointer to the display. The horrible hack to fix the build is just to redeclare the deprecated symbols in our header. This works (for now) for the size_t functions, but calling CGDisplayBaseAddress() results in this warning getting printed:

Apr 22 14:23:18  procfs[10539] <Warning>: CGDisplayBaseAddress is obsolete and returning an empty buffer for display 0x4280500

So screenshots (i.e. cat /proc/system/hardware/displays/0/screenshot.png > ~/Desktop/scn.png) don't work, and result in some variant of Resource busy for the client.

We need to find a new way to get the display buffer. For screenshot purposes, using CGDisplayCreateImage to copy the framebuffer should suffice. (However, for users wanting to do this, we should also find a new way to stomp on the framebuffer directly)

Had to do the following (I'm using the command line developer tools)...

diff --git a/Makefile b/Makefile
index 81774fe..a102c0b 100644
--- a/Makefile
+++ b/Makefile
@@ -5,7 +5,7 @@
 CC  ?= gcc
 CXX ?= g++

-CFLAGS_OSXFUSE=-D_FILE_OFFSET_BITS=64 -O -I/usr/local/include/osxfuse -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -Wall
+CFLAGS_OSXFUSE=-D_FILE_OFFSET_BITS=64 -O -I/usr/local/include/osxfuse -arch x86_64 # -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -Wall
 CFLAGS  :=$(CFLAGS_OSXFUSE) $(CFLAGS)
 CXXFLAGS:=$(CFLAGS_OSXFUSE) $(CXXFLAGS)
 LDFLAGS=-L/usr/local/lib -losxfuse -framework Carbon -framework IOKit -framework ApplicationServices -framework Accelerate -framework OpenGL -weak-lproc
diff --git a/procfs.cc b/procfs.cc
index 57ce86f..0a3e7eb 100755
--- a/procfs.cc
+++ b/procfs.cc
@@ -48,6 +48,8 @@
 #include "procfs_tpm.h"
 #endif /* OSXFUSE_PROCFS_ENABLE_TPM */

+using std::string;
+
 static int procfs_ui = 0;
 #define PROCFS_DEFAULT_FILE_SIZE 65536

I got procfs built for macOS 10.12. However trying to use it with FUSE for macOS v3.5.4 results in the below error:

mount_osxfuse: the OSXFUSE file system is not available (255)

Edit: I also have the compatibility layer installed.

On macOS Mojave, it is always running at 100% CPU since the first access.

Please add /proc/self symlink to refer the current process. Thanks.

Part of fixing the build for x86_64 involved stubbing the old SequenceGrabber API calls, which were removed along with the rest of the QuickTime C API in the transition to 64-bit.

The current hack is to just stub our functions and do nothing. No idea if that causes problems for other components. It probably does.

This all means that camera capture doesn't work.

We need to find out how to enumerate cameras with a 64-bit API.

For some reason, the vast majority of PIDs don't show up. For example, with ~280 processes running:

ls /proc
10539  371    373    388    4690   4691   56117  byname system

No idea why this is, but it also happened in the old 32-bit version.

As of 48023bb, where PID, CPUID, and DISPID are numbers, PNAME is the process name, and WID is the window id, the current layout is something like this:

/proc/PID
/proc/PID/carbon/
/proc/PID/carbon/name
/proc/PID/carbon/psn
/proc/PID/cmdline
/proc/PID/jobc
/proc/PID/paddr
/proc/PID/pcred/
/proc/PID/pcred/rgid
/proc/PID/pcred/ruid
/proc/PID/pcred/svgid
/proc/PID/pcred/svgid
/proc/PID/pgid
/proc/PID/ppid
/proc/PID/task/  # lots of subfiles
/proc/PID/tdev
/proc/PID/tpgid
/proc/PID/ucred/
/proc/PID/ucred/groups
/proc/PID/ucred/uid
/proc/PID/wchan
/proc/PID/windows/
/proc/PID/windows/all
/proc/PID/windows/identify
/proc/PID/windows/onscreen
/proc/PID/windows/screenshots/
/proc/PID/windows/screenshots/WID.png
/proc/byname/
/proc/byname/PNAME
/proc/system/
/proc/system/firmware/
/proc/system/firmware/variables
/proc/system/hardware/
/proc/system/hardware/camera/screenshot.tiff
/proc/system/hardware/cpus/CPUID/data
/proc/system/hardware/displays/DISPID/info
/proc/system/hardware/displays/DISPID/screenshot.png
/proc/system/hardware/lightsensor/data
/proc/system/hardware/motionsensor/data
/proc/system/hardware/mouse/data

We have unique things, but we're also missing lots of stuff, like from Linux

/proc/PID/cmdline
/proc/PID/cwd
/proc/PID/environ
/proc/PID/exe
/proc/PID/fd/
/proc/PID/fdinfo/
/proc/PID/maps
/proc/PID/mem
/proc/PID/root
/proc/PID/status

which let you access the process's environment variables and file descriptors.

There's also cooler stuff from Plan 9, like

/proc/trace
/proc/PID/ctl
/proc/PID/note
/proc/PID/noteid
/proc/PID/notepg
/proc/PID/ns
/proc/PID/regs
/proc/PID/segment
/proc/PID/status
/proc/PID/wait

which allow sending control messages to the process (like start, stop, trace), sending notes (i.e. arbitrary string signals that Plan 9 replaced the BSD signals like SIGINT with), tracing any process that has had trace written to its ctl, accessing the register values of a process, and other things.

All of this (except maybe notes, which are even too cool for Linux) should be implementable on OS X.

There's also our /proc/system/, which should have more in common with sysfs and Plan 9's /dev.

It complies on macOS High Sierra now, but now I get this error when trying to use procfs binary like: sudo procfs /proc -f

BTW, I have Fuse for macOS 3.7.1 installed.

The current README was taken from https://github.com/osxfuse/filesystems unchanged. The system requirements should be updated, and it should list the current capabilities and limitations of procfs. In particular, the differences between this and Linux's procfs should be listed.