Re: /proc fs implementation under hurd
I believe the /proc placeholder directory is just a linuxism from some of
the base debian packages, so do not draw any conclusions from its
existence.
There are no particular plans to implement a /proc filesystem.
If you would like to write one, more power to you.
Indeed, "translator" and "filesystem" are somewhat interchangeable terms in
the Hurd and what you would be writing is certainly a translator.
To start with, you need get a feel for writing a translator.
The files trans/hello.c and trans/hello-mt.c in the Hurd sources
are trivial "hello world" translators (a single-threaded version and a
multi-threaded) to give you a start at the basic idea. There is
substantially more work (and less code to easily guide you) involved in a
translator that provides directories rather than a single file node.
The other aspects of the work are how you get at all the information you
might want. This information (what is "process state" in Linux) is divided
into four pieces in the Hurd: virtual memory, threads, and POSIX process
state maintained in the proc server, and POSIX process state maintained in
each process by the C library.
The virtual memory and threads are provided by the Mach microkernel, and
along with the IPC state, these form a Mach task. (There is a one-to-one
correspondence between Mach tasks and Hurd processes.)
The `vminfo' program (source in utils/vminfo.c) will give you a feel for
what a process's virtual memory state looks like. The job of providing a
mappable file interface for a task's address space is already done by the
`task' store type (source in libstore/task.c), which would be used by a
translator like storeio; but I don't think that has really been tested, so
it might be broken. Anyway, that's about the least complicated piece of
the puzzle (in that it's a whole huge world of complication that is already
mostly handled elsewhere).
All of the other information I mentioned is already accessed by `ps', and
the code that does that is in the `libps' library. You might want to just
use that, depending what you want to do with all the information. Reading
that library should give you an idea where all the pieces come from and how
they are acquired. (Run ps with different options and format strings on
various processes to get a feel for what each datum means, and then go look
in the libps source code to see what the data structure for that looks like
and how libps finds the information.)
Reply to: