Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!sol.ctr.columbia.edu!bronze!cica!travis!greg From: greg@travis.cica.indiana.edu (Gregory TRAVIS) Newsgroups: comp.unix.sysv286 Subject: Re: Kernel Definition Message-ID: Date: 24 May 91 17:49:24 GMT References: <1423@necis.UUCP> <29696@hydra.gatech.EDU> <48JBS77@xds13.ferranti.com> Sender: news@cica.indiana.edu (News System) Organization: Indiana University Lines: 53 Nntp-Posting-Host: travis.cica.indiana.edu In <48JBS77@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <29696@hydra.gatech.EDU> ken@dali.cc.gatech.edu (Ken Seefried iii) writes: >> Your friend has absolutely no idea what he's talking about. In >> any traditional Unix system (V6, V7, Sys[35], BSD), the kernel >> is never swapped. >Weren't there some varieties of 2BSD that had an overlayed kernel on the >PDP-11? But that was pretty late in the life of 2BSD, when they were putting >all sorts of 4BSD stuff in it. I think it was 2.11 that started doing this. >(when was the last time you ran into an overlayed program?) Not overlayed in the traditional sense. From 2.8BSD and beyond, the kernel text (program) size had bloated beyond the 64K barrier. The solution was to modify the linker so that multiple "overlays" of the kernel were linked to begin at the same spot. What you ended up with was a microkernel whos size was a multiple of 8K. Then you had a whole bunch of chunks of the rest of the kernel laying around that were 64K - into which you put the various other parts of the kernel. The PDP-11 segment registers allowed the 64K program space to be divided up into eight 8K segments. With the above scheme, the kernel could be 300K of code - the crt0.o code and the code tacked onto the beginning of every function took care of modifying the segment registers on the fly to map in the appropriate code for whatever syscall was going on. For performance reasons you usually wanted to make sure that stuff like machdep.c, the trap code, the tty driver, the disk drivers, and the scheduler all lived in the microkernel. There was no function call overhead when calling routines in the microkernel. You also wanted to put routines that were likely to call each other in the same "overlay." The highest overhead was encountered when a routine in overlay A called a routine in overlay B. Swapping out parts of the kernel was never part of the plan. All of the code for the kernel, even if it was 300K, was locked into core from system startup to shutdown. All in continguous memory. Only the hardware segment registers were modified to bring the appropriate pieces of this code into the 64K "execution window." This overlay scheme was also used at the application level. Big Emacs would have been impossible without it! And it was almost completely transparent to the programmer. greg -- Gregory R. Travis Indiana University, Bloomington IN 47405 greg@cica.indiana.edu Center for Innovative Computer Applications