kurt@wucs.UUCP (Kurt H. Haserodt) (01/16/85)
If anybody has implemented a feature which will give you your running process status (and possibly other system status info) upon the entry of a certain control code, I would like to obtain the kernel (and other) changes required. I know that others have done this, but, after searching my archive of news, can find no source. Please either send the package along or respond by mail saying you have such a thing. Requests for my results will be honored. Thanks in advance. -- Kurt Haserodt ..!ihnp4!wucs!kurt Box 1045 Washington University (314)-889-6160 St. Louis, MO 63130 USA
Ron Natalie <ron@BRL-TGR> (01/18/85)
We have done this for 4.2 BSD. We print out the process number and the UID/GID for each process along with a description of what it is waiting for (i.e. processes reading the terminal have TTYI). This is headed with a line containing the load average. It is easy to do this for almost any UNIX system. I keep putting it into every UNIX system I come to. I've done it to PWB and even later systems. -Ron
Mike Muuss <mike@brl-tgr> (01/20/85)
BRL has implemented ^T in the kernel, along with some other neat stuff. (For 4.2 BSD). To get a copy of our system, send us 4 reels of magtape and a copy of your 4.2 and System V licenses. Best, -Mike Muuss (301)-278-6678 AV 283-6678 FTS 939-6678 ArpaNet: Mike @ BRL UUCP: ...!{decvax,cbosgd}!brl-bmd!mike Postal: Mike Muuss Leader, Advanced Computer Systems Team Computer Techniques and Analysis Branch Systems Engineering and Concepts Analysis Division U.S. Army Ballistic Research Laboratory Attn: AMXBR-SECAD (Muuss) APG, MD 21005
tim@callan.UUCP (Tim Smith) (01/23/85)
Cithep has had this feature for years. ^T ( or whatever you have it set to ), tells you the amount of real, system, and user time since the last ^T, the text, data, and stack sizes, the state of the process ( running, sleeping, waiting for terminal I or O, waiting for buffers, etc ), and the number of page faults ( "hard" and "soft" ), and of course, what is running. There might be something else. Kernel changes are simple, since it is implemented as a signal. It is a user mode program that does all the work. I believe that the only hard part about writting the program is deciding WHICH process to show info about. Note that the process that waits for ^T spends most of it's time pause()ing, and so does not use many system resources. Also, since it only reads the namelist and only has to open /dev/kmem once, it gets very good response. -- Duty Now for the Future Tim Smith ihnp4!wlbr!callan!tim or ihnp4!cithep!tim
pedz@smu.UUCP (02/05/85)
Response 3 of this note states that they implemented ^T to generate a signal which a user process traps and processes. I didn't do it that way. I simply changed the tty driver. The other method however seems very attractive since it allows a user to determine what should be printed out. Also, my implementation could not print out any info from the user space since the ^T was processed at interrupt time. The signal method would cure that problem. Any diffs available? Perry