Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: /dev/kUmem and other memory questions
Message-ID: <6007@umcp-cs.UUCP>
Date: Thu, 23-May-85 18:56:43 EDT
Article-I.D.: umcp-cs.6007
Posted: Thu May 23 18:56:43 1985
Date-Received: Fri, 24-May-85 22:46:05 EDT
References: <437@cadre.ARPA>
Lines: 55

> I know that lots of programs (e.g. ps) [read other processes' memory]
Distribution: net
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 50

> via /dev/kmem.  With that, am I correct in stating that you just
> examine the namelist and you have the location in the CURRENT /dev/kmem
> (subject to change without notice, dependent on number of variables,
> their size, etc.).

nlist'ing /vmunix gets you the positions of static things in /dev/kmem.
They aren't likely to move without the system going down first.  Usually
you need to also follow some of these static pointers to some dynamic
stuff which *can* change.

> It states in my 4.2 mans that "per process data for the current process
> is at virtual 0x7ffff000".

This isn't really true: it's at 0x80000000-UPAGES*NBPG (machine/vmparam.h
#define's USRSTACK as this same value).  On Vaxen, you can read your u.
area with

	struct user u;

	u = *(struct user *)USRSTACK;

which is useful for routines like unexec (transforms a running process
into an a.out image).

> Another question I had was what is /dev/kUmem?

kernel Unibus memory (it's the same as /dev/kmem, but reads and writes
are done a 2-byte word at a time).  Occasionally useful for faking
device drivers from user-level code.

> ... what happens when you run a program.  It appears that it 1) reads
> your program, 2) loads it 3) somehow runs it (must be magic).

When you exec() something, it throws away all your current memory and
gets some new memory for the new file (which must start with an a.out header
describing how big it is) [well, actually it's more efficient than that].
The proc structure doesn't change (except for statistics).  The u. area
gets lots of new information though.

> My question stems with can you touch that running executable somehow
> (just like you can touch the running system through /dev/kmem).

Yes, but it's ugly: you have to use /dev/kmem and /dev/mem in
machine-dependent ways (you get to simulate the Vax page lookups for
processes that are loaded).  The ``gcore'' program (4.2BSD) makes a
core image from a running process this way.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland