cwr@pnet01.cts.com (Will Rose) (09/04/90)
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 ----------------------------------------------------------------------- "You think that your career | Will Rose will suffer if Dr. Kenworthy | learns you have the poisoned | UUCP:{nosc ucsd hplabs!hp-sdd}!crash!pnet01!c corpse of our fiancee in the | ARPA:crash!pnet01!cwr@nosc.mil ice box?" | INET:cwr@pnet01.cts.com Evelyn Waugh, "The Loved One" | UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!cwr ARPA: crash!pnet01!cwr@nosc.mil INET: cwr@pnet01.cts.com
valke@wundt.psy.vu.nl (Peter Valkenburg) (09/07/90)
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).