Hi,
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 :-)
-antrik-
