Aliasing text and data segments of a process

John Chambers jc at minya.UUCP
Thu Feb 4 14:28:50 AEST 1988


In article <7209 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <246 at vcvax1.UUCP> naren at vcvax1.UUCP (naren) writes:
> >	Now, if you REALLY want to do this, you could write a new system call 
> >like mktext(vaddr, length)...
> 
> In case it isn't obvious to everyone, the reason why this can be done is that
> the operating system kernel has special privileges and can therefore shuffle
> around virtual->physical address mappings and associated attributes, but an
> ordinary user-mode process cannot do this itself.  That's why IPC via shared
> memory requires kernel support, for example.

Uh, no it doesn't.  (Well, maybe it does on a PDP-11 :-).  I've personally
worked on one system where we had shared memory with no support whatsoever
from the kernel.  The poor li'l kernel didn't even suspect we were doing it.

Guess how we did it?  Give up?  (OK, turkey, tell 'em!)

The processor in question came up with the MM registers mapped in the obvious
way, so that real and virtual memory were identical.  The kernel was kept in
ignorance of the last few MM registers, which by some strange coincidence just
happened to point to real memory 'way up in the address space.  (Did I say that
this was a machine with 32-bit addresses?  Well, it was.)  This chunk of real
memory was quite distant from the main memory, and when the kernel did its scan
for usable memory, it didn't find the high chunk.  Like most Unix kernels, it
only believed in a single contiguous piece of real memory.

The effect was to map this small chunk of memory into the virtual address space
of every process, without the knowledge of the kernel.  Most processes also
didn't realize it was there.  Our run-time library did, and did some very
interesting things with it, and very fast.

OK, it's a kludge.  But then, memory-mapped anything is exactly the same
kind of kludge.  Just classify it as a memory-mapped device (as are quite
a lot of network interface boards these days), and it all makes sense.  
For instance, go talk to CMC about their ethernet boards.

This example had the advantage that we didn't have to try to figure out 
how the Sys/V shm package works.  I mean, it was pure elegance in comparison
with how AT&T would have liked us to do it. (:-)

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)



More information about the Comp.unix.wizards mailing list