We currently don't expose any process control to the user. As a first real step towards Plan9 utilization of the filesystem, I propose a procfs that lists running processes to be mounted at /sys/proc. A later iteration could do something interesting with process "file" contents, perhaps modeling them as directories with individual attributes as sub files, similar to the Linux procfs.
File names would use their task name (<executable>.<index> like kernel.0) to be more descriptive. These files would not be able to copied or moved, so we'll have to figure out how that plays out in practice. Would we need a special file mode that tools check? If we don't do that, is it ok if we get a shallow "export" to a file in the case of a copy?
One thing that seems obvious and should work out fine is removing these files with rm would be a terminate on the process.
We currently don't expose any process control to the user. As a first real step towards Plan9 utilization of the filesystem, I propose a
procfs
that lists running processes to be mounted at/sys/proc
. A later iteration could do something interesting with process "file" contents, perhaps modeling them as directories with individual attributes as sub files, similar to the Linux procfs.File names would use their task name (
<executable>.<index>
likekernel.0
) to be more descriptive. These files would not be able to copied or moved, so we'll have to figure out how that plays out in practice. Would we need a special file mode that tools check? If we don't do that, is it ok if we get a shallow "export" to a file in the case of a copy?One thing that seems obvious and should work out fine is removing these files with
rm
would be a terminate on the process.