GNU/Linux compatible procfs pseudo-filesystem
I wish to provide a sophisticated procfs pseudo-filesystem to “the Hurd”. An implementation of /proc pseudo-filesystem already exists in hurdextras repository. After skimming through the code it is clear that it needs a lot of rework and tuning. Experiences from GNU/Linux have proven procfs to be a very useful facility in implementing many of the process management tools. So the goal of this project is to rework on the existing procfs on “the Hurd” so that its not only reliable and robust but also more importantly it is fully compatible with the GNU/Linux procfs. The project thus aims at making the GNU/Linux process management tools like top, sysctl, kill, skill, nice, snice, pgrep, free, tload, uptime, fuser, killall, pidof, pstree, etc., to run out of the box.
This phase involves improving my translator programming skills by gaining hands-on experience in it and becoming well versed in it. I will also go through the Hurd code to understand its architecture in depth and will read documentations related to obtaining process related information in Hurd. This phase also involves the migration of existing procfs to use libnetfs.
This phase involves the analysis of previous migration. Also involves interacting with the mentor, the Hurd community and other people involved in development of ps. tools to draw the exact design of the proposed procfs including the algorithms required for coding.
Finishing up the migration to libnetfs based on the finalized design and making necessary changes to the existing procfs. Coding up to /proc/<pid>/exe in the features list.
Involves coding of the features from /proc/<pid>/environ, up to /proc/<pid>/maps. These contain most of the information required for ps. tools and hence form the heart of the project. Will be completed by mid-term evaluation deadline.
Coding the rest of the features in the list including any necessary features that may be added in the analysis phase.
Closely interacting with the community and requesting them to help me in overall testing and reviewing and making changes as per their suggestions. Also involves testing with the ps. tools and consolidating the documentation.
Final phase of testing and fixing remaining bugs. Working with the community to merge the project with the CVS HEAD of Hurd. Documentation reviews, making necessary changes as per the suggestions and wrapping up the documentation.
- /proc filesystem that uses libnetfs. Using this library makes it easier for implementing a large set of functionalities and hence makes the implementation robust.
- The core GNU/Linux compatible /proc filesystem with functionalities to support and provide information for ps. tools like procps, psmisc etc.
Non-code deliverables include an exhaustive Documentation. This documents the code of the Hurd's procfs which explains in detail the implementation of each of the functionalities of procfs implemented during the course of this project.
Clone URL: git://github.com/madhusudancs/procfs.git
- Packages Ported: [http://www.madhusudancs.info/parted-hurdi386 parted-1.7.1]
- Packages Porting in progress: autogen_1:5.9.4-1. Error installing texlive-bin. Error tracked to some post installation scripts of texlive-bin. Problem seems to be in fmutil. Trying to debug.
- Have to start coding libnetfs skeleton for procfs translator.
Target for next week
Task To be completed by Status Now
- Finish Defining the necessary netfs call backs 25-05-2008 Completed
- Create Directories for each process with pid directory name 27-05-2008 Completed
- Create stat file for each process within this directory and
put atleast 1 information into it 31-05-2008 In Progress
- Hurd Hacking Guide (Have Concentrated mainly on Translator part)
- Linux Kernel Implementation of procfs
Code Being Read
- procfs implementation in Linux kernel
- ftpfs (In Hurd main)
- cvsfs (In Hurd extras)
- xmlfs (In Hurd extras)
- httpfs (In Hurd extras)
- gopherfs (In Hurd extras)
- libfuse (In Hurd extras)
- procfs (libtrivfs based, In Hurd extras)
The number of minor faults the process has made which have not required loading a memory page from disk.
The number of major faults the process has made which have required loading a memory page from disk.
The number of jiffies that this process has been scheduled in user mode.
The number of jiffies that this process has been scheduled in kernel mode.
The standard nice value, plus fifteen. The value is never negative in the kernel.
Number of threads in this process.
The time in jiffies the process started after system boot.
Virtual memory size in bytes.
Resident Set Size: number of pages the process has in real memory, minus 3 for administrative purposes. This is just the pages which count towards text, data, or stack space. This does not include pages which have not been demand-loaded in, or which are swapped out.
The time in jiffies before the next SIGALRM is sent to the process due to an interval timer.
Number of pages swapped (not maintained).
Cumulative nswap for child processes (not maintained).
PF_* fields defined in (Not Linux compatible, but nearly says the something Linux says)
The nice value ranges from 19 to -19.
The number of jiffies that this process’s waited-for children have been scheduled in user mode.
The number of jiffies that this process’s waited-for children have been scheduled in kernel mode.
total program size
resident set size
I know where the information is available roughly, but need to look in detail to extract the exact information.
The number of minor faults that the process’s waited-for children have made.
The number of major faults that the process’s waited-for children have made.
The bitmap of pending signals.
The bitmap of blocked signals.
The bitmap of ignored signals.
The bitmap of caught signals.
Current limit in bytes on the rss of the process (usually 4294967295 on i386).
The address above which program text can run.
The address below which program text can run.
The address of the start of the stack.
The current value of esp (stack pointer), as found in the kernel stack page for the process.
The current EIP (instruction pointer).
Signal to be sent to parent when we die.
This is the "channel" in which the process is waiting. It is the address of a system call, and can be looked up in a namelist if you need a textual name. (If you have an up-to-date /etc/psdatabase,
CPU number last executed on.
Real-time scheduling priority
Aggregated block I/O delays, measured in clock ticks (centiseconds).
- May, 14, 2008
- May, 18, 2008
- May, 28, 2008
- June, 1, 2008
- June, 2, 2008
- June, 4, 2008
- June, 5, 2008 (3 commits, 00:30 HRS, 02:30 HRS, 11:15HRS, all in IST)
- June, 9, 2008
- June, 19, 2008 (Targets 1 and 2 successfully accomplished. Duration between the commits became inevitably longer because of the large amount of time spent on debugging the code.)
Name : Madhusudan.C.S
Email : firstname.lastname@example.org
Blog : http://www.madhusudancs.info
Detailed proposal: http://www.madhusudancs.info/gnu-hurd-procfs-proposal
Google Summer of Code Site Link: Abstract