[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Requesting for review of the Draft proposal for - procfs

From: Madhusudan C.S
Subject: Re: Requesting for review of the Draft proposal for - procfs
Date: Sun, 30 Mar 2008 01:07:15 +0530

Hi Olaf, Carl and all,
          I have submitted a totally reworked proposal through Google Web App. This proposal reflects all the suggestions you have made previously. I written my proposal so that it falls in line with the Hurd's requirements at the moment as you people have told me. The same proposal is pasted below for the review of the entire community. I request to all of you to go through the proposal and give your suggestions on it which will help me to improve it further.

    Also thanks a lot for spending your invaluable time in reviewing my proposal and also for the suggestions and comments you have given.

The proposal is given below.

GNU Hurd : 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 ps,
top, vmstat, sysctl, w, kill, skill, nice, snice, pgrep, free,
tload, uptime, fuser, killall, pidof, pstree, etc., to run out of
the box.

Project Details

   To begin with, I would be migrating existing procfs code which
uses libtrivfs, to use libnetfs throughout procfs. The necessity
is that libtrivfs is a library which is best suitable for
filesystems providing a single directory or file. Since procfs is
now implemented as a virtual filesystem with a large number of
files and directories, it needs a more reliable and robust library.
"libnetfs" caters to this need as it provides functions for both
Network file systems and large virtual file systems.

   The next stage is the heart of the project. In this stage all
the files and directories that are expected of a GNU/Linux
compatible /proc pseudo-filesystem(Linux procfs doc.[Ref1])
are implemented using the libnetfs library. The functionalities
that form the immediate requirements for running procps, psmisc
and related tools(ps. tools henceforth) are implemented during
this stage of the project. The functionalities that will be
implemented are listed below.

   1.  /proc/<pid>/cpu
   2.  /proc/<pid>/cwd
   3.  /proc/<pid>/root
   4.  /proc/<pid>/exe
   5.  Correcting the problems of /proc/<pid>/environ
   6.  Making existing /proc/<pid>/stat fully Linux compatible,
       this is the core file which provides most of the information
       necessary for ps
   7.  Making existing /proc/<pid>/maps Linux compatible
   8.  /proc/<pid>/statm
   9.  Making existing /proc/version Linux compatible
   10. Finding and correcting problems in /proc/uptime, so that
       this too is Linux compatible
   11. /proc/sys/net/*
   12. /proc/meminfo

   Other features will be added to this list after studying their
feasibilities and necessities. Details of each of these files and
directories and their necessities will be provided in detail in my

   With these features of procfs ready, the next stage of the project
is to test these implementations with the Linux versions of ps. tools
so as to ensure that the prime goal of the project is accomplished.
Bugs that arise during testing are fixed so as to ensure that all
ps. tools work out of the box on the Hurd.
Benefits to Hurd

Rewriting procfs to use libnetfs instead of the liptrivfs makes it
easier to implement large virtual filesystems. All the ps. tools
written for Linux will be capable of running on the Hurd out of the
box. Since these tools use only the features of procfs, it reduces
of a lot of efforts which would be otherwise required to port these
tools to use the Hurd's libps library which is not a good idea at
the moment.

   Also GNU/Linux's ps. tools are continuously evolving to provide
increasing number of functionalities and improvements. Thus
providing a compatible procfs makes much more sense than to use the
libps method since, when the new features are added to these tools
we need not again port the improvements but simply make them to run
out of the box, since it is more likely that procfs remains the same.
If procfs itself changes, even then it wont take too much of an
effort in making this change reflect in our procfs.

   Benefit to the user((and developers) community is that they can
now use Linux's ps. tools without waiting for it to be ported all
over to the Hurd which means faster availability of these tools
on Hurd to users.


   1. /proc filesystem that uses libnetfs. Using this library makes it
      easier for implementing a large set of functionalities and hence
      makes the implementation robust.
   2. The core GNU/Linux compatible /proc filesystem with functionalities
      to support and provide information for ps. tools like procps, psmisc

   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.

Project Schedule

   The project is planned to be completed in 7 major phases. Every
phase includes documenting the progress during that phase, so it is
not mentioned specifically at each phase. Also the three coding
phases involve testing and reviewing for those phases and
incorporating the suggestions and making changes in the code based
on the test results and community requirements. The timeline and
duration of each of these phases is given below:

   1. Initial preparation and migration
      (Community Bonding Period: has already started – May 25th)
        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.

   2. Analysis and Design (May 26th – June 11th )
        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.

   3. Coding Stage I (June 12th – June 22nd )
        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.

   4. Coding Stage II (June 23rd – July 13th)
        Involves coding of the features from /proc/<pid>/environ,
        up to /proc/<pid>/maps. These contain most of the infor-
        mation required for ps. tools and hence form the heart of
        the project. Will be completed by mid-term evaluation

   5. Coding Stage III (July 14th – July 26th )
        Coding the rest of the features in the list including
        any necessary features that may be added in the analysis

   6. Final Testing and evaluation (July 27th – August 8th )
        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.

   7. Packaging and Wrap-up (August 9th -  August 18th )
        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.


   I am already comfortable with the bug-hurd mailing-list and IRC
channel #hurd@freenode.net. I will be able to contact my mentor in
above two forms and will also be available through google-talk(jabber)
and yahoo! chats. I am also comfortable with CVS and SVN since I was
the SVN administrator for 2 academic projects.

About Me

   I am a 3rd Year undergraduate student pursuing Information Science
and Engineering as a major at BMSCE, Bangalore, India(IST). Have been using and
advocating Free Software(FS henceforth) from past 5 years. Have been
one of the main coordinators of BMSLUG. Have coordinated various events
including Swatantra Tech Fest - an all day FS Fest, Session by RMS,
Hack Fest (a competition in our college). Have won few Coding
Competitions since I was 13 years, the major one being a State level
BASIC Programming competition at 13.

   Have been actively participating in various FS Communities by
reporting bugs to communities like Ubuntu, GNOME etc and writing
patches for Drupal.

   I have a fair understanding of concepts of C and have nearly 3 years
of programming experience in C. I have basic understanding of the Hurd
architecture and have gone through the Hurd Hacking Guide. I also have
gained some knowledge on Translator programming. I need to brush up on
my knowledge to convert it into skills by gaining some hands on

   I have a working installation of Debian GNU/Hurd. I don't have words
to say about it. I am out of words to describe it. Its simply amazing.
I have been compiling few small programs and few translators on it.

   Since I am working with few FS communities I have a good
understanding of FS Development methodologies of communicating
with people, using Issue trackers like Bugzilla, Wishlists, Changelogs,
coding and testing.

   Lastly I want to express my deep commitment for this project and
Hurd. I'm fully available this summer without any other commitments,
will tune my day/night rhythm as per my mentor's requirement and assure
a dedicated work of 50 hours/week. Also I'll assure that I'll continue
my commitments with Hurd well after GSoC. If you find any part of this
proposal is not clear please contact me.

Important Links and URLs

   [Ref1] http://users.sosdg.org/~qiyong/lxr/source/Documentation
   [Ref2] Detailed proposal : http://madhusudancs.byethost13.com/
   My Hurd blog : http://madhusudancs.byethost13.com/hurd
   My CV : http://madhusudancs.byethost13.com/sites/default/files

P.S:  I request you to please see my Detailed proposal to know more about me,
my experiences on GNU/Hurd and other answers to questions asked in Hurd wiki
for writing GSoC proposal.

Thanks and regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]