OK, this is 1 level deep into our yak shavery, I started working on some changes to acme for my self and I realized I needed to develop some of these changes on a VM, since running multiple acme’s on the same box is a bit of a pain.
What I realized is I don’t have a straightforward way of controlling and updating processes running on another machine, and started thinking about how to address that situation. First solution that popped in to my head was writing a gRPC server of some sorts but I quickly backed out of that and figured that was probably not a great idea. Then it occurred to me proc(3) has a beautiful design and would probably work really well for my use case.
So the things I need to develop this version of acme is simple
- start a process on a remote server
- update the process executable
- stop the process
- trace the process
- read the process dump for debuging reasons
The idea here is not to implement the plan9 design 1:1, but rather take design hints for this system and implement it in a way that makes sense for this use case.
/proc already exists on linux, and it would be pretty straight forward to expose that as a 9p server. This is not that.
Let’s start reading the man page and get a sense of what’s going on
The proc device serves a two–level directory structure. The first level contains the trace file (see below) and numbered directories corresponding to pids of live processes; each such directory contains a set of files representing the corresponding process.
My initial thought was to use
mkdir to create a new process, but, that requires us to actually know what know what the pid is going to be of this thing we are creating. Whilst that’s doable do we really want to do that? After that’s not how we start processes in Plan9 or Linux.
So we’ll create a file in our rprocfs called
/rproc/rc. The interface is going to read a stream of text and return a pid.
% echo "acme -m /mnt/acme" > /rproc/rc /rproc/1