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.
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 blog[Ref2].
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.
Deliverables
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 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.
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 deadline.
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 phase.
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.
Communication
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 experience.
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.
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.