Access to kmem - System namelist - 'ps' etc

[Rob Warnock]

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.
For one "reasonable" implementation of system calls to fetch kernel tables,
go look at a copy of the TOPS-10 Monitor Calls Manual (I hear they're still
sold at some local DEC offices) and look at the "gettab" call and the data
structures it references.

- There are "n" tables, sub-indexed by item number. New tables (added as the
  kernel functionality changes) are added to the end. The low numbers don't
  change across releases. Often the sub-index is the job (UNIX "process")
  number. Much more (but not all) of the per-job information is kept in main
  memory than in UNIX (i.e., the "proc" tables are bigger and the "upages" are
  smaller). Functions are provided to assist in finding things on swap space.

- Tables can be variable length, and range-checking is done when you ask
  for an item.

- Some tables are priviledged to the super-user "[1,2]"; some are wide
  open; and some can be read by anyone if you are asking about "this"
  job (but only [1,2] can ask about other jobs).

- As expected, all of the tables and all of the fields and all of the magic
  values within fields have symbolic names. Unfortunately, only languages
  with macro capabilities (such as MACRO-10 or BLISS) can easily get at them.
  (In UNIX read "as" and "C".)

- Provisions are there (and used) to handle sub-tables of arbitrary
  extent, such as when you have multiple CPUs and want per-CPU data
  rather than per-system (TOPS-10/SMP supported up to 6 CPUs, last time
  I looked), such as # of interrupts by CPU, or idle time by CPU, etc.

- For any table, you can get the address of the table (if you are [1,2]).

- Instead of /dev/mem, per se, there are the general "peek" and "poke" calls,
  for those (hopefully rare) times one needs to twiddle bits. (c.f. next para.)

- A system call named "spy" (apt name) allows the kernel itself to be
  mapped read-only into your address space, ENORMOUSLY speeding up "systat"
  (a.k.a.  "ps") and "sysdpy" (a.k.a. "mon" in net.sources recently).

- TOPS-10 has a restricted form of setuid programs ("jacct" programs), so
  all of this can be hidden safely for ordinary users to access (like "ps").
  [See Note]

- There is MUCH MUCH more in these tables than I have ever seen displayed
  on any TOPS-10 program, or any 4.1bsd program for that matter. One sometimes
  wonders at the overhead of maintaining the data in the tables! (although
  much of it there just to help DEC's internal developers tune the system).
  But looking more closely one sees that you're only paying for pointers
  to tables that have to be there anyway (pointers are cheap).

- Along with the "gettab" facility, there is the "meter" facility which allows
  a data-gathering program to activate "meter points" in the kernel. The program
  gets sent an event record each time control passes through such a meter point.
  One can reduce the number of events recorded by qualifying the event with such
  things as job number, number of times per event, contents of some data field,
  etc.

All in all, I think UNIX hackers could gain a number of good ideas by browsing
through the manual for this ancient but venerable O.S. -- in particular, the
software-interrupt, async I/O, and real-time features should drop into UNIX
quite nicely (inasmuch as they were added progressively to TOPS-10 itself).

	[Note] It's my understanding that the Bell Labs patent on "setuid"
	applies only to cases where the setuid is an attribute of the FILE,
	and also only when the "uid" to set to can be a VARIABLE, since systems
	such as TOPS-10 had the restricted case of setuid-root (based on a
	kernel table of magic filenames) some time before UNIX.


Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
Envoy:	rob.warnock/kingfisher
USPS:	510 Trinidad Ln, Foster City, CA  94404