INTRODUCTION: Here we describe the structure of the /proc filesystem for the Hurd. Under the Hurd, we provide a translator called 'procfs' which is intended to provide the filesystem structure and some equivalent functionality to the /proc filesystem on other systems. Because of the flexibility of the Hurd, the /proc filesystem is provided as an external package rather than being built directly into the Hurd. This gives the user the opportunity to more easily make changes to it and tweak it to his or her needs. DESIGN CONSIDERATIONS: In order to provide maximum flexibility, the Hurd's /proc filesystem is available in various modes of operation, selectable when the translator is invoked. For example, the following command starts up the Hurd proc settrans translator in Linux 2.4 compatible mode. With no arguments, this is the default. filesystem /proc /hurd/procfs --linux24-compatible Other modes of operation are not yet available, and it is asked that when making extensions to the translator, that other modes of operation not interfere with the compatibility modes. The intention is to create a native format for the Hurd which makes more sense and is better organized than the Linux /proc filesystem without eliminating the "legacy" mode of operation. ON THE LINUX-2.4 EMULATION OF /proc: Some things are not implemented because there is no equivalent in the Hurd. Some are not implemented because I couldn't figure out a good way to do them. This document lists all of the things implemented and not with a brief explanation of each. To use the proc filesystem, you need only set up a translator for the mount point you wish to use. This should be a command something like this: $ settrans /proc /hurd/proc Now, by listing the /proc filesystem contents, you can see what's there and use it pretty much like the one for Linux. NOTE: . and .. are not yet fully implemented. This is a known bug. If you know how to fix it, please contact the author. /proc//cmdline Command line of the process obtained from the 'proc' server using 'proc_getprocargs()'. /proc//cpu Not implemented. Should show CPU state for the process. /proc//cwd Not implemented. Should be a soft link to the current working directory for the process. /proc//environ Environment of the process obtained from the 'proc' server using 'proc_getprocenv()'. This call always fails. I'm not sure why. /proc//maps Shows the same information that 'vminfo' shows when that utility is called. Note that this does not show exactly the same information as it's Linux counterpart. Deal with it. /proc//mem Not implemented. /proc//stat This one is only partially implemented. The data in this file is tedious to write and I didn't feel like sifting through it. /proc//statm Not implemented. /proc//status The following have no equivalents under the Hurd and so are set to zero: TracerPid FDsize CapInh CapPrm CapEff The following have equivalents under the Hurd but are not (yet) available through RPC calls. Uid/Gid Groups likewise. VmLck VmData VmStck VmExe VmLib SigPnd SigBlk SigIgn SigCgt Unlike Linux, the Hurd is multi-threaded, so the 'State' field is a little unusual. The 'state' is a combination of the states of the threads. As such it may have more than one state currently active. /proc/cmdline Not implemented. /proc/cpuinfo Mach does not provide all of the information that the Linux kernel shows in it's implementation of this file. Many of the items in this file are marked as 'TODO' since we're not sure where to get the information. /proc/devices Mach does not provide much information about the devices it supports. This is mostly hard-coded to the devices I happen to know Mach supports in a typical instance. If there is a better way to query Mach's devices, let me know. Also, unlike Linux/Unix, Mach does not use 'major' and 'minor' device numbers, so they are omitted from the listing because it doesn't make sense to talk about them on a Mach system. /proc/dma Not implemented. /proc/execdomains Not implemented. /proc/filesystems This is kind-of a cheap hack in that since filesystems are not "built into" the Hurd, they are external daemons, we make the (poor) assumption that filesystem translators reside in '/hurd' and end in 'fs'. Thus this one is easy to 'fool' into giving potentially incorrect results. /proc/interrupts Not implemented. /proc/iomem Not implemented. /proc/ioports Not implemented. /proc/kcore Not implemented. /proc/kmsg Not implemented. /proc/ksyms Not implemented. /proc/loadavg Shows the following information: / last_pid This is intended to be somewhat compatible with the Linux loadavg. /proc/meminfo Only some of this one is currently implemented. This is partially because the Hurd does not use disk cache per se. The Hurd lumps much of the memory management into huge pools and attempts to manage memory globally. As a result, the statistical information is not quite as granular as that for Linux. The 'total' memory is also a little bit fudged and should not really be relied upon too much. /proc/misc Not implemented. /proc/modules Like '/proc/filesystems', this one doesn't make too much sense under the Hurd. The closest thing I could find was the idea of reading '/hurd' and listing all of the files there. These are the closest thing to 'modules' that the Hurd has even though this is a little bit of a stretch. /proc/mounts Not implemented--There isn't really any way to do this one without exhaustively searching the filesystem tree, is there? /proc/partitions This is implemented using the device_getstatus call on each of the 'hd<0-4>' to find the partitions available. /proc/pci Not implemented. /proc/slabinfo Not implemented. /proc/stat Not implemented. /proc/swaps Not implemented. /proc/uptime Shows the amount of time the 'procfs' filesystem has been running. This is only a rough approximation of system uptime since the 'procfs' filesystem can be halted and restarted while the system is still up. The two fields show total uptime. The Linux counterpart shows uptime and idle time. This version does not have a good way to get idle time, so we just put uptime in that field instead. If you know better ways to get this information, please write and let me know. /proc/version This shows the same information that the 'uname' call gives. Not exactly what Linux shows but who cares? KNOWN BUGS/ISSUES: The '.' and '..' pseudo-directories on this filesystem do not work properly. This is a problem which should be fixed, but isn't very important right now since not many people really 'cd' into the /proc filesystem. If you do happen to do that, the easy way out it to 'cd' again to an absolute path name rather than 'cd ..'.