Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!mit-eddie!uw-beaver!uw-june!geops!rust!mhl
From: mhl@rust.DEC.COM (Mark Lucovsky)
Newsgroups: comp.unix.wizards
Subject: Re: Why "u." and not "u->" ?  (I'm reading Bach book)
Message-ID: <500@rust.DEC.COM>
Date: Wed, 13-May-87 14:57:20 EDT
Article-I.D.: rust.500
Posted: Wed May 13 14:57:20 1987
Date-Received: Sat, 16-May-87 08:12:57 EDT
References: <626@vixie.UUCP> <3568@spool.WISC.EDU>
Reply-To: mhl@rust.UUCP (Mark Lucovsky)
Distribution: world
Organization: DECwest Engineering
Lines: 16


The u. vs u-> is really an issue that deals with the location of the
kernel stack for the current process. Traditional ports assume that all
kernel stacks are based at the same virtual address (inside the u area).

If u-> were used then the trick in procdup() where resume is called to
arrange for the child process to return through syscall through the same
call chain that the parent entered with would become very complicated.

Another thing that u. solves is that during a fork, one process enters
_syscall, and two processes exit. If u areas were not mapped at the same
place then finding the u area for the second process would be tricky.

I worked on a system were kernel mode ran unmapped. We were unable to
use u. and therefore had to solve some very difficult problems. We even
considered copying u areas to a fixed location at every context switch.