bug-hurd
[Top][All Lists]
Advanced

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

Re: Student for GSoC 2008 - procfs


From: Madhusudan C.S
Subject: Re: Student for GSoC 2008 - procfs
Date: Sun, 30 Mar 2008 09:54:32 +0530

Hi Carl, Olaf and all,


I didn't mean to say that /proc/*/mem is problematic per se. I rather
meant that it's problematic to implement a Linux-compatible version in
the Hurd procfs translator.

The issue is that it's not possible to obtain all of the information
listed by the Linux variant. For one, in Linux, the file corresponding
the each mmap region is listed. In the Hurd, we have no central entity
keeping track of mmapped files. The kernel only knows about memory
objects. For each object, there is some process (called pager) backing
it -- usually some filesystem server. Mapping the memory object to a
file is entirely the individual pager's responsibility -- to obtain the
file name associated with a memory object, we would need a new interface
that allows asking the pager about it, or the actual process that
requested the mapping.

But that's not all. Linux procfs not only gives the path of the mapped
file, but also the inode and the major/minor device number of the
partition it is on. However, the Hurd doesn't have device numbers.
Rather, devices are described by the translators handling them. In case
of kernel-implemented devices, there is the Mach device name as
identifier, which is quite like major/minor device numbers, except that
it's an alphanumeric string rather than a pair of integers -- we can't
represent that in a compatible manner.

Filesystems can also live on devices not implemented by the kernel, and
thus having no device name at all. In some cases, the filesystem
location of the device translator could be used instead; but that's
again incompatible, and doesn't always exist either. Similary, some
filesystems on the Hurd are purely virtual (stuff like ftpfs for
example), and thus have no inodes.

The only way to unambiguously name any open file in the Hurd is to
provide the actual port. While it would be technically possible to do
that in a /proc filesystem I think, it would work totally different than
the /proc/*/mem on Linux...

The bottom line is that it's not possible to create a fully compatible
/proc/*/mem. But do we really need to? AFAIK this interface is used
mostly by debugging tools -- but debugging is very system-specific
anyways, and the tools need to be adopted to use whatever native
debugging interface the respective system provides; trying to be
compatible seems useless here.

Thus it's very important to find out whether /proc/*/mem is really
needed for ps, top and related tools; whether we need to implement it at
all, and if so, which parts...

Amazing explaination. I understood why /proc/<pid>/mem cannot be used. By a bit more googling I got it confirmed that this feature is absolutely needed for Debugging stuff and not exactly for procps tools, So I have dropped this from the list.

> /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.

> /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.

/proc/<pid>/environ is definitely needed by ps, a ps ewww <pid> returns the environment variables used by that process. 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 remember reading somewhere that its required for ps related tools too. I am not getting that link back now. So I am going through the code of procps and psmisc to find out. Please give me some time. Most of the features I had included had reasons and were not included simply without any knowledge on what they do, except a very few like /proc/<pid>/mem

> 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

Sounds like something that ps and/or top might use...

This is the core. This holds a huge lot of information required for procps, psmisc tools. In linux 2.6.x almost all the information provided by other files previously like information provided by /proc/<pid>/cpu have been moved to this file.

> /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

/proc/uptime is needed for obtaining idle process for top utility. Also /proc/version. I am not sure at the moment whether /proc/stat and /proc/swaps are required by vmstat for obtaining idle processes information. Assuming so I included in this list, I have removed it from my reworked proposal though, anyhow will decide whether we should include it after going through procps code.

> It would also be nice if we can provide
> /proc/sys/* features like
> /proc/sys/kernel/* - which reflects general kernel behaviors.

This is not needed for procps tools, I have removed from the list.
 
> /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.

> 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?




--
Thanks and regards,
 Madhusudan.C.S

reply via email to

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