Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!decwrl!sun!gnu From: gnu@sun.uucp (John Gilmore) Newsgroups: net.unix-wizards Subject: Re: Access to kmem - System namelist - 'ps' etc Message-ID: <1869@sun.uucp> Date: Thu, 13-Dec-84 03:30:32 EST Article-I.D.: sun.1869 Posted: Thu Dec 13 03:30:32 1984 Date-Received: Sat, 15-Dec-84 02:45:01 EST References: <126@dadla.UUCP> <93@redwood.UUCP> Organization: Sun Microsystems, Inc. Lines: 19 > Just a hint... Other systems have been faced with this problem in the > past. It might be worth looking around to see how others have addressed it. The Data General AOS and AOS/VS systems solved this problem cleanly. (Actually I'm impressed, now that I've seen Unix, at HOW cleanly they built a system with just about all the features of Unix, with many fewer wild kludges and many more features.) One of the defined system calls took a PID as argument and returned a struct giving info about the process. Think of it as "stat" on a process instead of a file. There was no reason to restrict access to this system call, so you could do it on any process. To find all the jobs in the system, start at pid 1 and recurse asking about all its daughters (that's part of the info returned). Note that the struct returned need not correspond to any particular data structure in the kernel, but can be built at the time you ask for it. Now maybe it took a day longer to write than 'ps', but in cleanliness it is certainly is closer to Heaven.