Martin Dalecki writes:
> breed@almaden.ibm.com wrote:
>> Actually the bloat/mess has to be somewhere. Either in userspace
>> trying to make sense/stay in sync with the kernel structures,
>> or in the kernel where it has the structures. Obviously everything
>> shouldn't go in /proc, but there things that are simplier either
>> in the kernel or in user space.
I rewrote ps. Properties of a good solution might be:
1. single system call returns an array
2. all values are 64-bit (larger values can be split)
3. binary data
4. reasonable choice over what data is returned
Of course, ps must use the Linux kernel 2.2.x /proc for a while.
>> In some of the embedded projects we do space is a big issue,
>> and /proc actually allows us to save space by not putting a lot
>> of tools (like ps) in the precious flash.
...
> Or just do size /bin/ps on a free BSD box and compare the reslut's
> with the same on linux (assuming you didn't compile the procps lib
> as shared...) Why do you think we have currently make bzlilo
> instead of make zlilo now?
You can use minimal.c to get a library-free 8 kB ps.
http://www.cs.uml.edu/~acahalan/linux/procps-991122.tar.gz
> The first race in /proc I can think of is for example the simple
> fact that ps doesn't really get a true snap of the systems state,
> there are chances that it will change under the feets of it...
It is not reasonable to get such a snapshot. If every process has
a full comand line and you have 32767 processes, you need over 4 GB.
Actually, that means ps is automatically broken on 32-bit systems.
-
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 : Sat Jan 15 2000 - 21:00:12 EST