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]<http://lkml.org/lkml/2006/3/10/224>.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 <http://lkml.org/lkml/2006/3/10/224>
--
Thanks and regards,
Madhusudan.C.S
