From: drew@ophelia.cs.colorado.edu (Drew Eckhardt) Subject: Re: problems with ps, pcomm95c+1 and more... Date: 28 May 1992 06:20:22 GMT
In article <8085@uqcspe.cs.uq.oz.au> rhys@cs.uq.oz.au writes:
>In <1992May26.053149.27469@colorado.edu> drew@juliet.cs.colorado.edu (Drew Eckhardt) writes:
>
>>>> This must be built from the unstripped kernel binary.
>>>
>>>Yes, but *how* do you build it?
>>>
>
>>ps -U <file>
>
>This must be the worst part of Unix. Ideally there should be a system call
>to get the ps statistics, so ps doesn't need to rebuild its database all the
>time (or even need a database). At the very least, would it be possible to
>add a new system call to Linux to return a pointer to a table of addresses
>in kernel memory? These addresses would be those required by ps to do its
>kernel lookup work. A table of strings (for the labels) and actual addresses
>to allow for easier expansion and less offset-dependence maybe.
See below.
>Sure, this call is not "standard Unix", but having to rebuild the kernel to
>use ps is plain grungy, and really isn't a good thing for those not
>interested in kernel hacking to be doing. (Yes, there are those of us who
>want to use Linux and not hack it :-) .
>
Pester Linus about providing the kernel nlist file (/etc/psdatabase) with
each new kernel binary.
BSD 4.4 does this with the "get kern info" (with some mangling through
the use of underscores) library function, which does either a syscall
on a live kernel, or does the right thing on a core dump of a dead kernel.