Fuse filesystem support #116
Description
It would be great if we had the natural generalisation of /proc to the allocation level, i.e. a filesystem that exposes allocations. E.g. this would allow scripting and introspection from the shell.
It also opens the big question of how to unify "big" files and "small" in-memory allocations, at the Unix filesystem API layer.
To get the filesystem running, the right design is probably a system-wide or user-wide mountable fuse filesystem, possibly per user, that exposes all processes or all of that user's processes. However, a more basic design would be a version of liballocs that simply mounts a fuse filesystem in some convenient per-process place, maybe using a /proc/pid/something directory as a mount point and re-exposing its contents. I have some preliminary partial code for this (not yet working, not public, but ask me if interested).
For the many-process design we would want some kind of ring buffer in shared memory, serializing the filesystem requests and responses. We could control this protocol although following fuse is probably sensible.
Is it OK to turn single-threaded into multi-threaded processes? Forking a fuse event-loop thread is quite an invasive change. One idea might be to use our syscall trapping instead, so that we process pending fs requests on each syscall and perhaps (for CPU-hammering processes) also on scheduler re-activation. (Doing them on a deschedule seems cleaner, but the kernel will not let us do this, for obvious secure-multiplexing reasons.) I don't currently know a way to hook re-activation on Linux but maybe there are tricks used by user-level threading libraries.