Path: utzoo!attcan!uunet!mcsun!hp4nl!star.cs.vu.nl!wundt!valke
From: valke@wundt.psy.vu.nl (Peter Valkenburg)
Newsgroups: comp.os.minix
Subject: Re: PC 1.5.10 ps.c
Summary: I should have mailed this, probably.
Message-ID: <1455@wundt.psy.vu.nl>
Date: 6 Sep 90 18:58:12 GMT
References: <4244@crash.cts.com>
Organization: VU Psychologie, Amsterdam, the Netherlands
Lines: 38

In article <4244@crash.cts.com> cwr@pnet01.cts.com (Will Rose) writes:
>valke@wundt.psy.vu.nl (Peter Valkenburg) writes:
> 
>>        1) Will Rose has provided a fix for a problem which isn't there -
>>           Ps neither requires kernel/mm/fs to be in standard places, nor
>>           that they always contain symbol tables.  You can pass the paths
>>           for kernel/mm/fs along with a ps -U, and they don't need to
>>           contain symbol tables afterwards.
> 
>As I understand the PC ps.c 1.5.10 code, and I've looked at it closely,
>when ps -U is run *either* the symbol tables must be in the kernel, mm and
>fs images currently in memory *or* kernel, mm, and fs images containing
>symbol tables must be on a path known to the user somewhere in the system.
>This feature proved a (minor) annoyance when I was continuously rebuilding
>the kernel, so I changed it.
> 
>Good luck with the next version - Will

Not exactly: ps does *nothing* with symbol tables in the memory image on which
the system is running: that is why you can effectively delete them from kernel
/mm/fs (let's call them "the holy trinity" :-) after a database has been
generated with ps -U, and build an image not containing any symbol tables.

I think I see your problem now, though:
You lose your /etc/psdatabase of an old image when you are running a new one,
and when you return to the old image its holy trinity was already stripped,
or perhaps gone entirely, so ps -U won't do any good.  A solution is to move
psdatabase to another place so you can savely do ps -U for the new image, and
move it back when you run the old system again.  You never need any symbol
tables after a first ps -U then.

To support this scheme completely, I will fix ps to allow creation of the
database for a holy trinity that is not actually in the image on which the
system runs at the time of the ps -U.  Right now, it occasionally crashes
when collecting the process information from an entirely mismatching image.

Hope this helps,
	Peter Valkenburg (valke@psy.vu.nl).