[Top][All Lists]

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

Re: Student for GSoC 2008 - procfs

From: olafBuddenhagen
Subject: Re: Student for GSoC 2008 - procfs
Date: Mon, 31 Mar 2008 01:58:44 +0200
User-agent: Mutt/1.5.17+20080114 (2008-01-14)


On Sun, Mar 30, 2008 at 09:54:32AM +0530, Madhusudan C.S wrote:

> > /proc/<pid>/cpu  -  Contains CPU state information of the process
> > > <pid> and exactly contains Current and last cpu in which it was
> > > executed.
> >
> In linux 2.4.x compatible mode this is required by top and related tools for
> CPU usage information, though this information is provided in
> /proc/<pid>/stat only.

Sorry, I don't quite understand this statement. How does Linux 2.4 come into 
play here? Is top using a legacy interface so that we need to provide it?...

> /proc/<pid>/environ is definitely needed by ps, a *ps ewww <pid>* returns
> the environment variables used by that process.

I see. I'm not sure ps itself is that important though, see my other mail. The 
tools we most urgently need are pkill, pgrep, killall, {,h,g}top. So usless 
these tools need it as well, I'd consider it lower priority...

> Also as of what I have found
> now /proc/<pid>/cwd is used by lsof <pid> to show all the files opened by a
> process which includes cwd also, this also requires /proc/<pid>/fd/* too.

I suspected that lsof would use this. Having lsof would be very nice, but it's 
not the highest priority either. I suggest you keep it on the list, but take 
the priority into account when deciding order.

> /proc/uptime is needed for obtaining idle process for top utility. Also
> /proc/version.

OK, I suspected that...

> /I am not sure at the moment whether /proc/stat and
> /proc/swaps are required by vmstat for obtaining idle processes information.

As I said in the other mail, vmstat is probably not really necessary. *top 
might use this information as well though, so we might need it nevertheless...

> > > /proc/sys/net/*  - which contains all the network related information on
> > the
> > > system.
> >
> I think this is required for fuser(part of psmisc), since it provides
> several network related information. This will also help to run netstat
> tools to run out of the box. If this is not part of the goal we can leave
> this as a goal, but still will be necessary to implement what are provided
> by fuser. Will confirm where fuser is obtaining tcp and udp information
> from.

I'd put fuser in a similar category as lsof -- nice to have but not crucial...

> > One more important feature that would be desirable is /proc/<pid>/fd -
> > > which contain the symlinks to all the files the process has opened
> >
> > That might be useful for some tools; but it has similar issues like
> > /proc/*/mem I think. But then, Linux also needs to do strange things
> > here for fd:s not corresponding to any filesystem location (like
> > pipes), so maybe that's not a problem...
> I did not get this part, can you please explain, but as I have said above
> /proc/<pid>/fd is required. So whats your take on it?

I was mostly thinking aloud here :-)

For /proc/*/mem, I explained that sometimes it's not possible to
associate mmaps with disk files. The same is true for fd:s -- not every
open fd corresponds to a file. But that is true for Linux as well, in
the case of pipes for example. Linux will show a magical string instead
of a real symlink in this case, something like pipe:[26001] . Tools
already need to cope with this, so it's not a problem if we just do the
same :-)


reply via email to

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