Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!+ From: Rick.Rashid@cs.cmu.edu Newsgroups: comp.os.mach Subject: Re: Bytes in Mach 3.0? Message-ID: Date: 18 Feb 91 16:45:45 GMT References: <2981@fai.UUCP> <1991Feb13.170901@ibmpa.awdpa.ibm.com> <1991Feb14.220240.26795@ico.isc.com> <62753@bbn.BBN.COM> <1991Feb15.214231.21348@watmath.waterloo.edu>, <1991Feb18.033855.4864@watdragon.waterloo.edu> Organization: Carnegie Mellon, Pittsburgh, PA Lines: 57 In-Reply-To: <1991Feb18.033855.4864@watdragon.waterloo.edu> We have made no attempt here to build or distributed a stripped down version of the Mach kernel. The existing distribution contains support for a variety of devices and displays, a kernel debugger and a bootstrap loader as well as the "Mach kernel" proper. For example: in a recent build I looked at the text size of various parts of the kernel. Machine dependent i386 code (for ISA architectures) amounted to about 85K bytes of which approximately 17.5K was machine dependent debugger support. The machine independent debugger code generated an additional 14K of code. The bootstrap loader was 13K and machine independent device support was approximately 22K. Overall, these components accounted for 135K of generated code. Strictly speaking, much of this code does not need to be loaded into the kernel image. We have experimented with versions of the kernel in which the bootstrap loader, default pager, and even ethernet and disk drivers reside outside the kernel. We have never discussed it, but in principle the debugger could be done that way as well. These enhancements will make there way out to the community as encorporate them into our internal releases via the anonymous ftp path. When looking at the rest of the kernel, a few things should be kept in mind as well. The size of machine independent code in the Mach kernel is inflated considerably by machine generated (i.e. MIG) remote procedure call or message stub code. About 40K goes into such interfaces although there is very little human written code involved. From a space perspective, the MIG generated code is far from optimal and could be handled by a simple interpreter working from table data supplied by the stub generator. Finally, the Mach 3.0 kernel has a number of compatibility hooks to support code written for older versions of Mach. This tends to inflate considerably the IPC size numbers in particular. A pure 3.0 environment could switch this code off. -Rick PS - One additional point should be made. One reason we have not put in the energy to set up "minimized" versions of the kernel is that so little of the runtime space of a real system consists of kernel binary. In older versions of Mach kernel stacks for threads easily consumed more then twice the amount of memory used by the kernel binary. While in principle these stacks were pageable, in practice nearly all were used frequently enough that they could be considered "real" memory taken from applications. The most recent versions have eliminated this entire cost category by eliminating separate kernel stacks for threads and using explicit continuations instead.