In article <88hrpq$6mhf7@fido.engr.sgi.com>, you write:
|> On Thu Feb 17, 2000 at 11:44:10AM +0000, Alan Cox wrote:
|> > Procfs is to a great extent the wrong answer to most of its uses, its more
|> > bloated than sysctl but does little more and its slow.
Alan is absolutely correct. /proc is an unbounded collection
of unrelated kernel data items. It has been used as a dumping
ground for everything that in traditional unix has been
obtained via /dev/kmem (which is worse, esp. on smp systems).
Some of the issues with /proc include localization and
internationalization issues (i.e. ascii strings) in
the kernel code (the kernel shouldn't need to be
localized insofar as possible); bounded buffer lengths
for e.g. /proc/pci, /proc/partitions, etc.
In the original /proc (SVR4/Solaris) [leaving plan9 aside],
it was, as the name suggests, a 'process' file system. It
was used to provide 'ps' and debugging facilities, primarily
to eliminate the 'ptrace' system call (and extend debugging
ability to multiple light-weight processes - which are the
scheduling entity which underlies pthreads).
In linux, however, /proc doesn't do most of this (it does
provide support for 'ps', but not for debugging), yet it
provides all kinds of kernel information unrelated to
processes.
At the bare minimum, it should probably be split into a
real /proc (perhaps initially providing only ps support,
but eventually subsuming ptrace) and perhaps a
/system, or /kernel pseudo-file-system which supports
the other uses. Appropriate user level utilities
should be written (a la ps) to format and display information
provided through the /kernel fs. The kernel makes binary
information available and the applications format and print
the information. This would make, e.g. sard and SGI's pcp
products more robust simply because they will no longer be
required to parse ascii text from /proc/partitions, etc.
Eliminating /kernel entirely and using sysdat is another
viable alternative for getting kernel information. Certainly
one which is more efficient (open ain't cheap).
|> How does one do the following without resorting to /proc?
|>
|> 1) Find what kernel is running (i.e. /proc/sys/kernel/osrelease)
like every other unix in existence: uname -a
|>
|> 2) Find a machine's free/total memory (i.e. /proc/meminfo)
meminfo command (which gets its data via sysdat or /kernel)
|>
|> 3) Find what modules are loaded (i.e. /proc/modules)
lsmod can certainly use sysdat or /kernel just as easily as
/proc.
|> 5) Find what devices are mounted on what filesystem (i.e. /proc/mounts)
|> (right now there _is_ no way to find what /dev/root is short of doing
|> a stat on "/" and then stating everything in /dev for a matching dev_t,
|> or using devfs, or doing what libc does -- believng whatever crap is
|> in fstab)
|>
mount(1)
|> 6) How does one find the pid of a process with a particular name
|> (think killall) without hunting through all the /proc/%d/cmdline
|> entries?
ps -ef | grep <name>
|>
|> 7) How does one implement ps without using /proc?
Of course you can use /proc for ps, that is what it was
originally designed for.
Now, while it is an elegent design, it is an inefficient
design as well. While running some very heavy-duty
database benchmarks (OLTP) on 4-processor linux box
a single 'ps' command can perturb the results significantly.
'top' is even worse.
scott lurndal
sr mts sgi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:19 EST