Path: utzoo!attcan!uunet!convex!killer!rpp386!root
From: root@rpp386.Dallas.TX.US (The Beach Bum)
Newsgroups: comp.unix.questions
Subject: Re: How do you find the user structure?
Summary: Very, very easily.
Message-ID: <9338@rpp386.Dallas.TX.US>
Date: 10 Dec 88 20:34:32 GMT
References: <214@fesk.UUCP> <13232@ncoast.UUCP>
Reply-To: root@rpp386.Dallas.TX.US (The Beach Bum)
Organization: Big "D" Home for Wayward Hackers
Lines: 45

In article <13232@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes:
>As quoted from <214@fesk.UUCP> by sverre@fesk.UUCP (Sverre Froyen):
>+---------------
>| I have tried to get Brandon's sysV version of w to work on my
>| National Semiconductor ICM3216 running SysV.2.2.  This is a
>| demand paged system and, as Brandon points out in the documentation,
>| w is unable to locate the user structure.  I have looked through
>| the system documentation and various include files but I am unable
>| to find the solution (I have no source).  I suspect I must start
>+---------------
>
>I've been trying to find it myself, via trial-and-error; I want to use it on
>a few demand-paged System V-based machines myself.  Anyone know what V.2.2
>and V.3.1 do with the ublock?

/dev/mem is a very fast device.  Searches on it are so simple as to be
obsurd.

Start with a finding SOME collection of information which will allow you
to identify the ublock as being your own.  The address of your own process
table entry is a real unique sort of number.  That item is no sweat to
find.

Next, stare at the proc structure to see what sort of information it
gives you.  p_daddr and p_caddr are two good guesses.  proc.h _usually_
has enough info for you to figure out which one it is.  Then, using the
macros in param.h or sysmacros.h or some other collection of headers,
make a really good guess about WHERE you expect the ublock to be.

Put the two of them together.  Start by finding your process table entry.
Save the address in the table where you found it, because you may need it
later.  Now, SEQUENTIALLY read all of the memory in /dev/mem trying to
find YOUR ublock.  When you do [ and you should sooner or later ... ],
you know you have found at least ONE block in the case of a demand paged
system.

If you aren't on a system which pages the ublock [ the ublock is
contiguous starting at some address ], you should be able to, with some
experimentation, deduce the formula used to locate the ublock.

If you ARE on a system where the ublock is not contiguous, you at least
should be able to determine the method used to store that one page.
Look at the page table entries [ god willing ... ], and once you have
figured out how you got that one page, you should be able to figure out
how to get the rest of them.