[ssug-malappuram] Fwd: Student for GSoC 2008 - procfs
- From: "Praveen A" <pravi.a@xxxxxxxxx>
- To: "Malappuram SSUG" <ssug-malappuram@xxxxxxxxxxxxx>, bms-lug@xxxxxxxxxxxxxxxx, rvcelinuxusersgroup@xxxxxxxxxxxxxxxx, glugc@xxxxxxxxxxxxxxx
- Date: Tue, 25 Mar 2008 13:35:28 +0530
Beautiful way of applying to summer of code. Anyone wanting to apply
should go through this discussion and provide as much info as possible
about the project/idea you are planing to apply. It has to be detailed
and you should have a clear idea of the task you are going to do. You
will have to read a lot of documents related to the project and try to
understand as much as possible.
Madhu,
Good work. Keep up the spirits.
Praveen
Forwarded Conversation
Subject: Student for GSoC 2008 - procfs
------------------------
From: Madhusudan C.S <madhusudancs@xxxxxxxxx>
To: bug-hurd@xxxxxxx
Date: २००८ मार्च २३ ००:५४
Hi all,
Sorry all of you. I am extremely sorry for being so late in
sending this mail. I am a prosepective GSoC 2008 student. I am very
much interested in the idea of implementing procfs on HURD. This idea
was proposed to me on our LUG (BMSLUG) mailing list a year back[1].
Back then I had very less knowledge of HURD and any UNIX system or
their variants in general as a programmer though I was using GNU/Linux
just like an end user from 3 years then. So I did not take up the task
then. Now I am much used to GNU/Linux and have learnt general API
programming on UNIX systems. Though I have not contributed any code to
the Linux Kernel directly, I have a little understanding of how the
code is structured and how it works.
So as soon as I saw the idea on the proposed projects list on 24th
I was very much inspired and motivated to take this project for this
Summer. I immediately thought of working on this. And I thought I
could post to the mailing list once I have a fair understanding of the
proc filesystem. Hence the delay in posting. I did go through few
guides and tutorials on procfs on GNU/Linux system. Main guides
include [2] and [3]. I am also going through the procfs Documentation
in the Linux 2.6 Kernel source located at
kernel-source/Documentation/filesystems/proc.txt[4]. Please give me
some time to go through it fully since it is a pretty huge
documentation and it takes some time to digest it. I hope you guys
understand how difficult it is to understand things for beginners like
me in the beginning.
I have a working Installation of the GNU system[Debian GNU/HURD
K-16], I checked out the CVS code of procfs in the hurdextras repo. I
also read the Documentation thats there in the CVS, the README
file[5]. I am also going through the code. I hope you people
understand that going through the entire code and understanding in
less than 5 days is quite difficult for beginners. Kindly co-operate.
I will defintely go through the code. Though I have understood what
translators are I am not aquainted with translator programming. I am
also learning that part still. Since the requirement says this project
would require "learning translator programming", I am learning it from
HURD Hacking Guide.
Since Google has given us the whole of April and May to build a
strong relationship with the community, I will utilize this time to
become well versed in translator programming, general HURD programming
and Hacking and also with the current implementation of procfs in
HURD. I will also utilize this time to draw a neat plan of what needs
to be done(though we would have comeup with a rough plan while
submitting the application itself, at this stage I would like to
refine things and make the plan rocksolid). So as soon as SoC begins
on May 28th I can start right away with coding.
So I request you all to guide me through this process and help me
come up with a proposal. I think its bit difficult to port all the
features in GNU/Linux procfs to HURD in 3 months by a single person,
though its not impossible(I also think its not necessary to port each
and every feature thats available in GNU/Linux). So by having a
discussion here we can finalize on what are the most important
requirements that we need to focus at the very moment and draw a
schedule for this summer so that the goals can be reached.
I think most important of all the features that are to be made
available are proc/<pid>/* features which are very important to
implement process related functionalities. So we need to focus on it
at the moment.
Those features include
/proc/<pid>/cpu
/proc/<pid>/cwd
correcting the problems in /proc/<pid>/environ
/proc/<pid>/mem
completing /proc/<pid>/stat
/proc/cmdline
/proc/swaps
We can also think of /proc/<pid>/attr/* features if they are feasible
and if you people suggest to go ahead.
What are your suggestions? Please Help me.
(This is only a rough idea of what can be done. I will draw the plan
after discussion here is complete. I am open for all your inputs. I
will be available in #hurd at the time which is convinient to you all.
Please inform me so I can make myself available at that time. Please
help me.)
[1] http://groups.yahoo.com/group/bmslug/message/361
Please see this if you have access to this post. The mailing list is
not moderated.
[2] http://www.aoc.nrao.edu/~tjuerges/ALMA/Kernel/procfs-guide/index.html
[3] http://www.nirendra.net/cms/procfs/user
[4]
http://users.sosdg.org/~qiyong/lxr/source/Documentation/filesystems/proc.txt
[5] http://users.sosdg.org/~qiyong/lxr/source/Documentation/filesystems/proc.txt
--
Thanks and regards,
Madhusudan.C.S
"When liberty is taken away by force it can be restored by force. When
it is relinquished voluntarily by default it can never be recovered"
- Dorothy Thompson
--------
From: Madhusudan C.S <madhusudancs@xxxxxxxxx>
To: bug-hurd@xxxxxxx
Date: २००८ मार्च २३ ००:५७
Hey,
I am sorry I forgot to make a mention of this. As its mentioned
in the proposed ideas page I will also considering writing the code in
libnetfs rather than libtrivfs whereever possible.
[उद्धृत पाठ छिपा दिया गया है]
--------
From: Madhusudan C.S <madhusudancs@xxxxxxxxx>
To: bug-hurd@xxxxxxx
Date: २००८ मार्च २३ ०७:२९
Hi all,
Sorry for few mistakes in the mail, I was quite excited
while writing this mail.
>
>
>
> So as soon as I saw the idea on the proposed projects list on 24th I was very
> much inspired and motivated to take this project for this Summer.
The date there is March 17th and not 24th. Excuse me.
>
>
> Since Google has given us the whole of April and May to build a strong
> relationship with the community, I will utilize this time to become well
> versed in translator programming, general HURD programming and Hacking and
> also with the current implementation of procfs in HURD. I will also utilize
> this time to draw a neat plan of what needs to be done(though we would have
> comeup with a rough plan while submitting the application itself, at this
> stage I would like to refine things and make the plan rocksolid). So as soon
> as SoC begins on May 28th I can start right away with coding.
Sorry again the date hear must be May 26th. I am really sorry.
[उद्धृत पाठ छिपा दिया गया है]
--------
From: Madhusudan C.S <madhusudancs@xxxxxxxxx>
To: Praveen A <pravi.a@xxxxxxxxx>
Date: २००८ मार्च २३ ०७:३२
Hi Pravin,
I have mailed this one to bug-hurd mailing list. I am also
forwarding this to you. Please go through and give suggestions. Please
point out the mistakes. I have made some mistakes with regard to the
dates. Will it create a problem?? Since it was given their wiki that
mistakes mean no interest. Please help.
Thank you
[उद्धृत पाठ छिपा दिया गया है]
[उद्धृत पाठ छिपा दिया गया है]
--------
From: Olaf Buddenhagen <olafbuddenhagen@xxxxxxx>
To: "Madhusudan C.S" <madhusudancs@xxxxxxxxx>, bug-hurd@xxxxxxx
Date: २००८ मार्च २४ ०३:४१
Hi,
> Sorry all of you. I am extremely sorry for being so late in
> sending
> this mail.
You aren't late at all -- official application period is starting
only on monday :-)
> I did go through few guides and tutorials on procfs
> on
> GNU/Linux system.
[...]
> Please give me some time to go through it fully since it is a pretty huge
> documentation and it takes some time to digest it.
It's very good that you already looked into all this stuff :-)
Note that it's not a problem if you don't know every detail of Linux
procfs. Take a look into which parts of procfs are actually needed for
tools like procfs, and concentrate on implementing that...
> I have a working Installation of the GNU system[Debian GNU/HURD K-16], I
> checked out the CVS code of procfs in the hurdextras repo. I also read the
> Documentation thats there in the CVS [...]
> I am also going through the code. I hope you people understand that
> going through the entire code and understanding in less than 5 days is
> quite
> difficult for beginners.
Of course -- you seem to have done quite a lot already :-) You will
have enough time to understand the details. For now, having an idea
how stuff works in general and what you need to change is a very good
start :-)
> I think its bit difficult to port all the features in
> GNU/Linux procfs to HURD in 3 months by a single person, though its not
> impossible(I also think its not necessary to port each and every feature
> thats available in GNU/Linux).
Indeed, we don't need all features -- only what's needed for procfs,
top and similar tools.
> I think most important of all the features that are to be made
> available
> are proc/<pid>/* features which are very important to implement process
> related functionalities. So we need to focus on it at the moment.
> Those features include
> /proc/<pid>/cpu
> /proc/<pid>/cwd
> correcting the problems in /proc/<pid>/environ
> /proc/<pid>/mem
> completing /proc/<pid>/stat
> /proc/cmdline
> /proc/swaps
/proc/<pid>/mem is problematic. Do we really need it for procps etc?
I don't know enough about the others -- what they do, what they are
needed for. Could you give a short summary, why you think each one
important?
> (This is only a rough idea of what can be done. I will draw the plan after
> discussion here is complete. I am open for all your inputs. I will be
> available in #hurd at the time which is convinient to you all. Please
> inform
> me so I can make myself available at that time. Please help me.)
I will only be online again Wednesday evening. But most of the time,
someone else should be on IRC -- just keep in mind that people
sometimes need quite long before they can reply :-)
Most people are online during the day and evening in european
timezones -- roughly 12:00 to 24:00 UTC or so...
All in all, what you wrote above sounds quite promising -- I'm sure
you will be able to hand in a very good application :-)
-antrik-
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
--------
From: Madhusudan C.S <madhusudancs@xxxxxxxxx>
To: bug-hurd@xxxxxxx
Cc: Olaf Buddenhagen <olafbuddenhagen@xxxxxxx>, Praveen A <pravi.a@xxxxxxxxx>
Date: २००८ मार्च २४ ०९:११
Hi,
> Hi,You aren't late at all -- official application period is starting only on
> monday :-)
>
>
First of all thanks a lot in spending your invaluable time to
read such a long mail I have sent. Somehow I dont want to delay
submitting application to the last day. So I though posting after such
a long time was late. Before that I wanted to have a small discussion
about this project on the group, taking inputs from others, what they
would like to see as a part of procfs on Hurd. Since this takes quite
some time, I thought it was late. Anyhow thanks a lot for inducing
confidence in me.
> Indeed, we don't need all features -- only what's needed for procfs, top and
> similar tools.
>
>
> /proc/<pid>/mem is problematic. Do we really need it for procps etc?
After a bit of googling I found that /proc/<pid>/mem was
considered a problem due to the vulnarability it poses in allowing
other user processes to change the process map of other process which
consequently may crash the system requiring a reboot. Since this
happened in 2.2.x series of Linux kernel, the feature was totally
disabled in 2.4.x series. But there are some patches submitted by
third party developers[1].I think those patches will help us in
designing the whole solution itself in a different way when we start
designing.
If this was not the problem you were trying to mention please
tell me what it was.
> I don't know enough about the others -- what they do, what they are needed
> for. Could you give a short summary, why you think each one important?
>
>
Yeah sure, I will try to tell you what each of those features do,
but I am working on why each of them are needed for. I will be posting
on them in the subsequent mails.
/proc/<pid>/cpu - Contains CPU state information of the process
<pid> and exactly contains
Current and last cpu in which it was executed.
/proc/<pid>/cwd - Its a symlink which points to the current working
directory of the process
correcting the problems in /proc/<pid>/environ
- This contains values of Environment
variables for that process. But the
procfs doc in Hurd says it always fails.
And the author says he doesn't
know why. Have to work on it and fix it.
completing /proc/<pid>/stat
- This gives the process status in a form
not legible to humans. And the
need of this is just this. Let me try
to give an example thats given in the
Nirendra's blog I had linked earlier.
The 8th attribute in Linux's
/proc/<pid>/stat is a per process flag which
gives personal information of process.
By doing a logical AND of per
process flag and with the following
values we can obtain the information
thats given next to the values:
0x00000002 Process being created
0x00000004 Exiting
0x00000008 Dead
0x00000040 Process using super user privilage
0x00000200 Process dumping core
0x00000400 Process received some signal
0x00000800 Process allocating memory
0x00001000 Killed for out-of-memory
And so are attributes.
/proc/cmdline - Contains the command line arguments passed to Kernel
/proc/swaps - Contains swap space utilization function.
Also from additional searching and a bit of researching I have
found that it would be nice if I do include these features in the
list.
/proc/stat - Overall statistics about the system, such as
the number of page faults
since the system was booted.
/proc/version - In the current implementation only gives the
result of uname. But it would
be nice if we provide other details provided
by Linux versions such as gcc
version used to compile the kernel and the uptime.
/proc/uptime - It already seems to be implemented by looking at
the code. If there are any
problems and additional requirements I would
consider it again
It would also be nice if we can provide
/proc/sys/* features like
/proc/sys/kernel/* - which reflects general kernel behaviors.
/proc/sys/net/* - which contains all the network related information
on the system.
One more important feature that would be desirable is
/proc/<pid>/fd - which contain the symlinks to all the files the
process has opened
I would like to have the suggestions of all you people in working
out what features are needed and what are really not necessary for
Hurd. I request all of you to give your invaluable suggestions so that
it will help me to come up with a good proposal.
> I will only be online again Wednesday evening. But most of the time, someone
> else should be on IRC -- just keep in mind that people sometimes need quite
> long before they can reply :-)
>
> Most people are online during the day and evening in european timezones --
> roughly 12:00 to 24:00 UTC or so...
Ok fine thanks. I am used to #hurd IRC. I will be there most of
the time I am online. And also I have spoken to most of the guys
there.
> All in all, what you wrote above sounds quite promising -- I'm sure you will
> be able to hand in a very good application :-)
>
Thanks a lot for the compliments.
Can any of you please give me the contacts of the authors of
procfs which currently exists in the hurdextras repo viz. Jonathan
Arney and James Morrison, so I can discuss with those people too.
[1] http://lkml.org/lkml/2006/3/10/224
[उद्धृत पाठ छिपा दिया गया है]
--------
Other related posts:
- » [ssug-malappuram] Fwd: Student for GSoC 2008 - procfs
