D&I of 4.3 BSD

[Chris Torek]

In article <34 at daisy.UUCP> marlon at daisy.UUCP (Marlon Pearson) writes:
>... "The Design and Implementation of the 4.3 BSD Unix* Operating System"
>... On p. 80 it is talking about low-level context switching. It reads
>"... To make switching user structures as efficient as possible on the
>VAX, the system maps the physical memory associated with each process's
>user structure to a fixed location at the top of the user-mode virtual
>address space. ..."

>I am confused about a couple things. I am familiar with mapping virtual
>addresses to physical but not the other way around. So the first sentence
>has got me.

It does not mean `We go out and find the physical address, then magically
map it to a particular virtual address,' but rather `We choose a set of
physical pages in which to store a u. area, then set up a page map so that,
when we context switch into this process, these pages show up at a
particular virtual address (0x80000000 - UPAGES*NBPG).'

>"(This location is also at a fixed virtual address in the
>kernel's address space.)"

This really means `and by the way, we also give it a particular kernel
space virtual address'---in this case, since kernel code can reach into
user space directly, this is also 0x80000000 - UPAGES*NBPG.  If you
calculate this value you get 0x7fffec00; if you run `nm /vmunix' you
will find that `_u' is an absolute symbol whose value is 0x7fffec00.
In other words, the compiler (or more precisely, the linker) knows
that `&u' is `0x7fffec00', always.  No matter which process is running
at the time, the address of, e.g., u.u_ofile[] is the same.  The actual
value of u.u_ofile[0] (the file for descriptor 0 for the current process)
changes when the current process changes (during a context switch), but
the address of u.u_ofile[0] is always the same.

There is actually some more trickery with `double mapping' of physical
pages during fork() and during swapping, using Forkmap/forkutl, etc.
None of this is relevant to ordinary context switching, however.

Note that another approach (easy on VM machines) is simply to map the
u. area of each process into kernel virtual space only, giving each
one a different address, and maintain a pointer to the current `struct
user', changing it at each context switch.  This has some unfortunate
effects on signals, however (which currently `bounce off' user-space
code stored in the u. area).  It also makes addressing more difficult
(have to track down the current u. pointer).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris