Explain why Warner is right, and I am wrong, in the removing of the

file object.  Also explain some possible directions to re-implement it --
I'm not sure it should be, given the minimal application use.  (Other
than having the debugger automatically access the symbols for a process,
the main use I'd found was with some minor accounting ability, but _that_
depends on it being in the filesystem space; an ioctl access method would
be useless in that case.)

This is a code-less change; only a comment has been added.

1 files changed, 14 insertions, 0 deletions

diff --git a/sys/fs/procfs/procfs_mem.c b/sys/fs/procfs/procfs_mem.c
index 43652f1..df97979 100644
--- a/sys/fs/procfs/procfs_mem.c
+++ b/sys/fs/procfs/procfs_mem.c
@@ -314,6 +314,20 @@ procfs_domem(curp, p, pfs, uio)
  * wait() all maintain the p_textvp field in the
  * process proc structure which contains a held
  * reference to the exec'ed vnode.
+ *
+ * XXX - Currently, this is not not used, as the
+ * /proc/pid/file object exposes an information leak
+ * that shouldn't happen.  Using a mount option would
+ * make it configurable on a per-system (or, at least,
+ * per-mount) basis; however, that's not really best.
+ * The best way to do it, I think, would be as an
+ * ioctl; this would restrict it to the uid running
+ * program, or root, which seems a reasonable compromise.
+ * However, the number of applications for this is
+ * minimal, if it can't be seen in the filesytem space,
+ * and doint it as an ioctl makes it somewhat less
+ * useful due to the, well, inelegance.
+ *
  */
 struct vnode *
 procfs_findtextvp(p)