georgeb@fai.UUCP (George Bosworth) (02/12/91)
Considering the Mach 3.0 kernel and the Unix Server, could a kind soul tell me about how many bytes are in the respective load modules? And about how many device drivers are included in the figures? Thanks much. George H. Bosworth georgeb@fai.com or Fujitsu America B-2-7 uunet!fai.com!georgeb 3055 Orchard Drive San Jose CA 95134 1-408/432-1300 x5033
champlin@decwrl.dec.com (Virgil Champlin) (02/13/91)
I too would like to see some basic numbers for executable images of
the micro kernel. I am really jazzed about mach but would like to know
if it would be crazy to try and build a 68000 or i386 (somewhat special
purpose) machine and expect the micro kernel to take 128 or 256K?
Thanks much -virgil
--
Virgil Champlin champlin@nsl.dec.com
Palo Alto, CA
"I got it, I got it, I ain't got it."webb@ibmpa.awdpa.ibm.com (Bill Webb) (02/14/91)
In article <CHAMPLIN.91Feb12131759@virgil.pa.dec.com>, champlin@decwrl.dec.com (Virgil Champlin) writes: |> |> I too would like to see some basic numbers for executable images of |> the micro kernel. I am really jazzed about mach but would like to know |> if it would be crazy to try and build a 68000 or i386 (somewhat special |> purpose) machine and expect the micro kernel to take 128 or 256K? |> Thanks much -virgil |> -- |> Virgil Champlin champlin@nsl.dec.com |> Palo Alto, CA |> "I got it, I got it, I ain't got it." Here's some numbers for a 386 MACH 3.0 kernel (your mileage may vary): ls -lag STD+WS/mach_kernel -rwxr-xr-x 3 webb usr 332478 Feb 13 12:37 STD+WS/mach_kernel cccp:/space3/obj/ps2/latest/kernel(5) size !$ size STD+WS/mach_kernel text data bss dec hex 245728 31572 86728 364028 58dfc ---------------------------------------------------------------- The above views are my own, not necessarily those of my employer. Bill Webb (IBM AWD Palo Alto, Ca.), (415) 855-4457. UUCP: ...!uunet!ibmsupt!webb INTERNET: webb@ibminet.awdpa.ibm.com
rcd@ico.isc.com (Dick Dunn) (02/15/91)
webb@ibmpa.awdpa.ibm.com (Bill Webb) writes: > champlin@decwrl.dec.com (Virgil Champlin) writes: > |> I too would like to see some basic numbers for executable images of > |> the micro kernel... ... > Here's some numbers for a 386 MACH 3.0 kernel (your mileage may vary): ... > text data bss dec hex > 245728 31572 86728 364028 58dfc Either there's something here that deceives a typical, UNIXoid, naive under- standing of "size" output, or there's something very wrong. Does the text size somehow include non-kernel code? Is "size" getting fooled by some- thing? My confusion stems from the understanding that the Mach 3.0 kernel is supposed to be the "micro-kernel" version, and the belief that a 240 Kb kernel cannot reasonably be labeled "micro". Explanation/clarification, please? -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...But is it art?
fkittred@bbn.com (Fletcher Kittredge) (02/15/91)
In article <1991Feb14.220240.26795@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >webb@ibmpa.awdpa.ibm.com (Bill Webb) writes: >> champlin@decwrl.dec.com (Virgil Champlin) writes: >> |> I too would like to see some basic numbers for executable images of >> |> the micro kernel... >... >> Here's some numbers for a 386 MACH 3.0 kernel (your mileage may vary): >... >> text data bss dec hex >> 245728 31572 86728 364028 58dfc > >Either there's something here that deceives a typical, UNIXoid, naive under- >standing of "size" output, or there's something very wrong. Does the text >size somehow include non-kernel code? Is "size" getting fooled by some- >thing? My confusion stems from the understanding that the Mach 3.0 kernel >is supposed to be the "micro-kernel" version, and the belief that a 240 Kb >kernel cannot reasonably be labeled "micro". > >Explanation/clarification, please? Sure, how familar are you with modern operating systems? 245K of text with 31k of data is *VERY* small for a UNIXoid kernel. For example, here is the size of the Unix kernel on Sun, DEC and HP systems: VAX Ultrix 4.1 -rwxr-xr-x 1 root.wheel 848896 Feb 2 10:45 /vmunix* text data bss dec hex 655912 107008 817076 1579996 181bdc DECStation Ultrix 4.1 -rwxr-xr-x 1 root.wheel 2767956 Sep 24 09:42 /nfs/spcds1/root/vmunix* text data bss dec hex 1115968 119904 260256 1496128 16d440 Sun 3 O/S 4.1 -rwxr-xr-x 1 root 733407 Feb 14 11:39 /vmunix* text data bss dec hex 542064 93072 144488 779624 be568 Sun SPARCStation O/S 4.1 -rwxr-xr-x 1 root 1027466 May 26 1989 /vmunix* text data bss dec hex 802816 113952 103744 1020512 f9260 HP 9000s700 HP-UX 8.0 (PreRelease) -rwxr-xr-x 1 root 2 2093056 Jan 11 13:50 /hp-ux* 1401920 + 311276 + 335560 = 2048756 >-- >Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 > ...But is it art? Fletcher Kittredge Platforms and Tools Group, BBN Software Products 10 Fawcett Street, Cambridge, MA. 02138 617-873-3465 / fkittred@bbn.com / fkittred@das.harvard.edu
gamiddle@watmath.waterloo.edu (Guy Middleton) (02/16/91)
In article <62753@bbn.BBN.COM> fkittred@spca.bbn.com (Fletcher Kittredge) writes: > In article <1991Feb14.220240.26795@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: > >My confusion stems from the understanding that the Mach 3.0 kernel > >is supposed to be the "micro-kernel" version, and the belief that a 240 Kb > >kernel cannot reasonably be labeled "micro". > > > >Explanation/clarification, please? > > Sure, how familar are you with modern operating systems? 245K of text > with 31k of data is *VERY* small for a UNIXoid kernel. For example, > here is the size of the Unix kernel on Sun, DEC and HP systems: > [various huge numbers deleted] I don't think it is all that small. 4.3bsd on a VAX has text of similar size: text data bss dec hex 229784 166320 90048 486152 76b08 Note that it is probably more fair to compare 386 with VAX binaries than with SPARC, MIPS or HP-PA, since RISC code tends to occupy more space.
geoff@zoo.toronto.edu (Geoffrey Collyer) (02/16/91)
Dick Dunn: >> >My confusion stems from the understanding that the Mach 3.0 kernel >> >is supposed to be the "micro-kernel" version, and the belief that a 240 Kb >> >kernel cannot reasonably be labeled "micro". Fletcher Kittredge: >> Sure, how familar are you with modern operating systems? 245K of text >> with 31k of data is *VERY* small for a UNIXoid kernel. For example, >> here is the size of the Unix kernel on Sun, DEC and HP systems: Guy Middleton: >I don't think it is all that small. 4.3bsd on a VAX has text of similar size: > >text data bss dec hex >229784 166320 90048 486152 76b08 > >Note that it is probably more fair to compare 386 with VAX binaries than with >SPARC, MIPS or HP-PA, since RISC code tends to occupy more space. Here are some more `macro' kernel sizes, from a Sun 3 running a hybrid Ninth Edition system (dak's 9vr1, for those who know what that means): text data bss dec hex 200540 41084 311848 553472 87200 /unix This kernel is configured for 8 users and includes a very generous allotment of streams buffers, a couple on-disk file systems (bitmapped and non-bitmapped free lists), /proc, the client side of a network file system (netb), TCP/IP, and various goo left over from the Sun system (e.g. keyboard mapping line discipline). Please note that the Mach ``micro-kernel'', at least as recently distributed, is claimed to exclude networking and file system code, among other things, if memory serves. So one is left to wonder why a micro-kernel which one would expect to be stripped-down and tight, is somewhat larger and much less functional than a macro kernel. One can argue that the Bell Labs Research people are brilliant and thus produce smaller kernels and that Memory Is Cheap So Who Cares (if one is willing to ignore the increased complexity that usually accompanies increased size) but none of that really explains this large discrepancy. Certainly breaking up tightly-integrated code into separate modules produces some increase in code size, but this is incredible. And ignoring object size, a "wc -l" on the newly-available Mach 3.0 micro-kernel produced 102,821. A quick inspection reveals copyright notices, RCS revision history logs and 40-character identifiers all over, but surely that only accounts for a quarter of this size at most. Even the above-named more-functional macro kernel is only 78,420 lines, much of it inherited from SunOS. -- Geoff Collyer utzoo!geoff, zoo.toronto.edu!geoff
rcd@ico.isc.com (Dick Dunn) (02/18/91)
fkittred@bbn.com (Fletcher Kittredge) writes: > [excerpts from my article showing incredulity at 240Kb of text in 3.0] > Sure, how familar are you with modern operating systems?... To the extent that "modern operating systems" is neither an oxymoron nor an empty set, I think I'm reasonably familiar with them. (I'll take "modern" in the sense of "contemporary" since I think that's what was intended.:-) >...245K of text > with 31k of data is *VERY* small for a UNIXoid kernel. For example, > here is the size of the Unix kernel on Sun, DEC and HP systems:... [examples showing kernels containing 530-1370Kb of text] Yet there have been a couple of followups showing systems currently in use which have conventional (non-"micro") kernels smaller than the size of the 3.0 kernel. Even though there are huge UNIX kernels to be found, I don't think that a relative measure against them says much. It is almost always possible to find code worse than what you've got; a characterization of "less bad than XYZ" is much weaker than "good"! 240Kb of code is a lot in an absolute sense. BTW, I'm focusing on the text size because that's where the complexity is. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...But is it art?
fkittred@bbn.com (Fletcher Kittredge) (02/18/91)
In article <1991Feb15.214231.21348@watmath.waterloo.edu> gamiddle@watmath.waterloo.edu (Guy Middleton) writes: >In article <62753@bbn.BBN.COM> fkittred@spca.bbn.com (Fletcher Kittredge) writes: >> In article <1991Feb14.220240.26795@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >> >My confusion stems from the understanding that the Mach 3.0 kernel >> >is supposed to be the "micro-kernel" version, and the belief that a 240 Kb >> >kernel cannot reasonably be labeled "micro". >> > >> >Explanation/clarification, please? >> >> Sure, how familar are you with modern operating systems? 245K of text >> with 31k of data is *VERY* small for a UNIXoid kernel. For example, >> here is the size of the Unix kernel on Sun, DEC and HP systems: >> >[various huge numbers deleted] > >I don't think it is all that small. 4.3bsd on a VAX has text of similar size: > >text data bss dec hex >229784 166320 90048 486152 76b08 > >Note that it is probably more fair to compare 386 with VAX binaries than with >SPARC, MIPS or HP-PA, since RISC code tends to occupy more space. Sorry for confusing the issue by posting the figures for Sun O/S, Ultrix and HP-UX, even though they were enlightening. The point is that those operating systems are not modern operating systems; neither is 4.3 BSD, or the ninth Edition of Unix. All of the above are the last of the previous generation of operating systems. Modern operating systems are designed from the ground up to support parallel processors (NUMA and UMA), distributed systems and object oriented programming. the above systems are single threaded, and have distributed name services, shared memory and IPC/RPC tacked on as an afterthought. A better comparision would be between Chorus, Ameoba and Mach 3.0. regards, fletcher Fletcher Kittredge Platforms and Tools Group, BBN Software Products 10 Fawcett Street, Cambridge, MA. 02138 617-873-3465 / fkittred@bbn.com / fkittred@das.harvard.edu
sef@kithrup.COM (Sean Eric Fagan) (02/18/91)
In article <1991Feb17.233812.18908@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >BTW, I'm focusing on the text size because that's where the complexity is. How many strings are there in the mach kernel? Remember that mach is (apparantly) compiled with gcc, which puts strings into text space, not data. That might or might not add something to it, but it should be considered. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
ccplumb@rose.uwaterloo.ca (Colin Plumb) (02/18/91)
>> In article <1991Feb14.220240.26795@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >>> My confusion stems from the understanding that the Mach 3.0 kernel >>> is supposed to be the "micro-kernel" version, and the belief that a 240 Kb >>> kernel cannot reasonably be labeled "micro". I must agree. For all the VM functionality in Mach, I'll allow it 128 K but wish for less. Something is seriously wrong with 240K. gamiddle@watmath.waterloo.edu (Guy Middleton) wrote: >I don't think it is all that small. 4.3bsd on a VAX has text of similar size: > >text data bss dec hex >229784 166320 90048 486152 76b08 > >Note that it is probably more fair to compare 386 with VAX binaries than with >SPARC, MIPS or HP-PA, since RISC code tends to occupy more space. Another VAX, same site, different configuration:: text data bss dec hex 220608 82548 66860 370016 5a560 4.3BSD on an HP 9000/236 (68010): text data bss dec hex 246752 27392 54152 328296 50268 The larger test size is probably due to debugging code; the system is a bit flaky... We need the old utzoo, which was constrained to 64K split I&D. For comparison, a system V release 4 /unix on a 68030: text data bss dec hex 702704 117252 313936 1133892 114d44 Ouch! -- -Colin
rock@cbnews.att.com (Y. Rock Lee) (02/18/91)
In article <1991Feb16.002946.5711@zoo.toronto.edu> geoff@zoo.toronto.edu (Geoffrey Collyer) writes: >Please note that the Mach ``micro-kernel'', at least as recently >distributed, is claimed to exclude networking and file system code, >among other things, if memory serves. So one is left to wonder why a >micro-kernel which one would expect to be stripped-down and tight, is >somewhat larger and much less functional than a macro kernel. 245K of text is not "micro-kernel" at all in my opinion, especially when all the networking and file system code are excluded. Also, it's a little bit misleading to simply use the output from "size" to prove that UNIX is a monster, because it includes all the drivers you have in your system. One needs to do a little more in order to get some fair numbers. Y. Rock Lee
Rick.Rashid@cs.cmu.edu (02/19/91)
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.
lance@motcsd.csd.mot.com (lance.norskog) (02/19/91)
Folks, I think these numbers comprise the micro-kernel with the BSD Unix 'server' bolted on its side in an unholy fashion. Yes? No?
tritsche@Informatik.TU-Muenchen.DE (Stefan Tritscher) (02/20/91)
In article <1991Feb16.002946.5711@zoo.toronto.edu| geoff@zoo.toronto.edu (Geoffrey Collyer) writes: |Dick Dunn: ||| |My confusion stems from the understanding that the Mach 3.0 kernel ||| |is supposed to be the "micro-kernel" version, and the belief that a 240 Kb ||| |kernel cannot reasonably be labeled "micro". | |Fletcher Kittredge: ||| Sure, how familar are you with modern operating systems? 245K of text ||| with 31k of data is *VERY* small for a UNIXoid kernel. For example, ||| here is the size of the Unix kernel on Sun, DEC and HP systems: | |Guy Middleton: ||I don't think it is all that small. 4.3bsd on a VAX has text of similar size: || ||text data bss dec hex ||229784 166320 90048 486152 76b08 || ||Note that it is probably more fair to compare 386 with VAX binaries than with ||SPARC, MIPS or HP-PA, since RISC code tends to occupy more space. | |Here are some more `macro' kernel sizes, from a Sun 3 running a hybrid |Ninth Edition system (dak's 9vr1, for those who know what that means): | |text data bss dec hex |200540 41084 311848 553472 87200 /unix | |This kernel is configured for 8 users and includes a very generous |allotment of streams buffers, a couple on-disk file systems (bitmapped |and non-bitmapped free lists), /proc, the client side of a network file |system (netb), TCP/IP, and various goo left over from the Sun system |(e.g. keyboard mapping line discipline). | |Please note that the Mach ``micro-kernel'', at least as recently |distributed, is claimed to exclude networking and file system code, |among other things, if memory serves. So one is left to wonder why a |micro-kernel which one would expect to be stripped-down and tight, is |somewhat larger and much less functional than a macro kernel. One can [...] |-- |Geoff Collyer utzoo!geoff, zoo.toronto.edu!geoff They don't say what they mean with 'micro'. Maybe they mean micro-functional not micro-size ;-> Sorry - could not resist, Stefan
Rick.Rashid@cs.cmu.edu (02/21/91)
Good joke. The fact of the matter is that, in many ways, Mach provides substantially more functionality that a 4.3BSD or similar kernel provides. Specifically: 1) VM - Mach's VM is substantially more sophisticated than 4.3BSD. It provides for large, sparse address spaces, copy-on-write, a well-defined layering of machine independent and dependent memory mapping code, etc. Mach also provides for the allocation of memory objects by user programs and external paging. 2) IPC - Mach provides a secure, extensible IPC facility with a variety of features designed to simplify or improve the implementation of multithreaded servers. Moreover, the speed of IPC is critical and much complexity of code in the IPC parts of Mach is due to a need for fast IPC operations. 3) Parallelism - Mach provides multiple threads per address space. Mach provides support for multiprocessors and multiprocessor scheduling including the dynamic allocate of processors to threads. It also supports multiple scheduling classes and provides the mechanism necessary for efficient implementation of multithreaded programs. Mach (and systems like it) are best described as "system software kernels". They provide key software abstractions of hardware functionality (tasks, threads, ports, messages, memory objects) which allow traditional system services such as file systems, data bases, window managers, etc. to be efficiently implemented outside the kernel. In fact, Mach is defined in such a way that even its own functionality can be implemented outside the kernel. Memory objects, ports, and even tasks and threads can be effectively implemented or simulated by user programs in such a way that no other Mach program can distinguish these "external" objects from the internal ones. The kernel itself is a Mach task with multiple Mach threads of control operating within it and it makes use many of the same IPC and VM calls used by user programs. I think the key point here is not "is mine bigger or smaller than yours", but rather, is my kernel defined and implemented in such a way as to allow system applications to be efficiently implemented above it. If it is, then you can use that kernel as the basis for many new operating systems and system applications without having to resort to placing ever larger amounts of code in supervisor state.
lance@motcsd.csd.mot.com (lance.norskog) (02/21/91)
lance@motcsd.csd.mot.com (lance.norskog) writes: >Folks, I think these numbers comprise the micro-kernel with the BSD Unix >'server' bolted on its side in an unholy fashion. Yes? No? So it's just the micro-kernel? All right, all right, here's another theory: the micro-kernel contains a lot of functionality which allows you to easily add on protocols, file systems, device drivers, regular programs, AND bolts a number of processors together in a clean, extensible way without forcing all the inefficiencies of normal symmetric spin-lock style UNIX machines. All this functionality controls the size of the architecture; even if you don't have the features linked in the core is still big because you CAN link in the features. Enough whistling in the dark: time to download the freed sources. Lance
webb@ibmpa.awdpa.ibm.com (Bill Webb) (02/22/91)
In article <2931@motcsd.csd.mot.com>, lance@motcsd.csd.mot.com (lance.norskog) writes: |> lance@motcsd.csd.mot.com (lance.norskog) writes: |> |> >Folks, I think these numbers comprise the micro-kernel with the BSD Unix |> >'server' bolted on its side in an unholy fashion. Yes? No? |> |> So it's just the micro-kernel? |> |> All right, all right, here's another theory: ... |> ... |> Enough whistling in the dark: time to download the freed sources. |> |> Lance Ok, If I'd known I'd start such a lot of thrashing around I'd have either held back from answering the original question (how big was the microkernel?) or posted more information. Here's a summary of the output of the size command for each major component, followed by the details: 14348 880 256 15484 3c7c Sub-Total ddb 45340 32 0 45372 b13c Sub-Total ipc 39828 2728 0 42556 a63c Sub-Total kern 16768 1732 0 18500 4844 Sub-Total mach 1760 260 0 2020 7e4 Sub-Total mach_debug 39792 200 4 39996 9c3c Sub-Total vm 21528 624 18 22170 569a Sub-Total device 13132 340 0 13472 34a0 Sub-Total boot_ufs 5044 28 0 5072 13d0 Sub-Total intel 19944 15628 0 35572 8af4 Sub-Total i386 53404 6000 27 59431 e827 Sub-Total i386at 270888 28452 305 299645 4927d Total For this particular mach_kernel (MK42), the size command gives: text data bss dec hex 278496 29796 26844 335136 51d20 mach_kernel.MK42.STD+WS So the above accounts for almost all of the text+data (bss is harder to handle as the size command doesn't give most of it since it's in "common"). Here's all of the component information (exercise: find out what's missing!) text data bss dec hex 128 16 0 144 90 db_access.o 1024 0 0 1024 400 db_aout.o 1176 16 0 1192 4a8 db_break.o 1496 568 0 2064 810 db_command.o 1760 124 0 1884 75c db_examine.o 928 0 0 928 3a0 db_expr.o 1112 0 0 1112 458 db_input.o 1408 12 0 1420 58c db_lex.o 404 16 0 420 1a4 db_output.o 824 0 0 824 338 db_print.o 1052 0 0 1052 41c db_run.o 1076 60 256 1392 570 db_sym.o 260 0 0 260 104 db_trap.o 512 52 0 564 234 db_variables.o 940 16 0 956 3bc db_watch.o 248 0 0 248 f8 db_write_cmd.o 14348 880 256 15484 3c7c Sub-Total ddb text data bss dec hex 2096 0 0 2096 830 ipc_entry.o 1116 0 0 1116 45c ipc_hash.o 356 20 0 376 178 ipc_init.o 8364 0 0 8364 20ac ipc_kmsg.o 1148 4 0 1152 480 ipc_marequest.o 1372 0 0 1372 55c ipc_mqueue.o 2260 0 0 2260 8d4 ipc_notify.o 2372 0 0 2372 944 ipc_object.o 2940 0 0 2940 b7c ipc_port.o 612 0 0 612 264 ipc_pset.o 6264 0 0 6264 1878 ipc_right.o 616 0 0 616 268 ipc_space.o 2224 0 0 2224 8b0 ipc_splay.o 372 8 0 380 17c ipc_table.o 148 0 0 148 94 ipc_thread.o 1640 0 0 1640 668 mach_debug.o 6472 0 0 6472 1948 mach_msg.o 4968 0 0 4968 1368 mach_port.o 45340 32 0 45372 b13c Sub-Total ipc text data bss dec hex 316 0 0 316 13c ast.o 820 8 0 828 33c bootstrap.o 304 0 0 304 130 debug.o 2088 16 0 2104 838 exception.o 680 0 0 680 2a8 host.o 1352 0 0 1352 548 ipc_host.o 448 0 0 448 1c0 ipc_kobject.o 2404 0 0 2404 964 ipc_mig.o 544 8 0 552 228 ipc_sched.o 2544 0 0 2544 9f0 ipc_tt.o 644 136 0 780 30c kalloc.o 1176 4 0 1180 49c lock.o 1084 32 0 1116 45c mach_clock.o 408 36 0 444 1bc mach_factor.o 436 0 0 436 1b4 machine.o 2048 40 0 2088 828 printf.o 592 0 0 592 250 priority.o 2724 0 0 2724 aa4 processor.o 216 0 0 216 d8 queue.o 4044 268 0 4312 10d8 sched_prim.o 572 0 0 572 23c startup.o 364 4 0 368 170 syscall_emulation.o 700 0 0 700 2bc syscall_subr.o 104 2088 0 2192 890 syscall_sw.o 2524 12 0 2536 9e8 task.o 5452 24 0 5476 1564 thread.o 596 0 0 596 254 thread_swap.o 72 0 0 72 48 time_stamp.o 424 0 0 424 1a8 timer.o 440 12 0 452 1c4 xpr.o 3708 40 0 3748 ea4 zalloc.o 39828 2728 0 42556 a63c Sub-Total kern text data bss dec hex 4788 376 0 5164 142c mach_host_server.o 2536 240 0 2776 ad8 mach_port_server.o 8444 976 0 9420 24cc mach_server.o 252 40 0 292 124 memory_object_default_user.o 748 100 0 848 350 memory_object_user.o 16768 1732 0 18500 4844 Sub-Total mach text data bss dec hex 1760 260 0 2020 7e4 mach_debug_server.o 1760 260 0 2020 7e4 Sub-Total mach_debug text data bss dec hex 3488 8 0 3496 da8 memory_object.o 1320 0 0 1320 528 vm_debug.o 5036 20 0 5056 13c0 vm_fault.o 104 0 0 104 68 vm_init.o 1988 0 0 1988 7c4 vm_kern.o 12244 24 0 12268 2fec vm_map.o 7844 48 0 7892 1ed4 vm_object.o 1816 28 0 1844 734 vm_pageout.o 4868 52 4 4924 133c vm_resident.o 1084 20 0 1104 450 vm_user.o 39792 200 4 39996 9c3c Sub-Total vm text data bss dec hex 364 0 0 364 16c blkio.o 2632 92 0 2724 aa4 chario.o 840 0 0 840 348 cirbuf.o 820 0 0 820 334 dev_lookup.o 608 0 0 608 260 dev_name.o 4064 84 0 4148 1034 dev_pager.o 532 48 0 580 244 device_reply_user.o 1972 160 0 2132 854 device_server.o 3152 184 0 3336 d08 device_user.o 132 0 0 132 84 device_init.o 3368 0 0 3368 d28 ds_routines.o 2436 32 0 2468 9a4 net_io.o 608 24 18 650 28a subrs.o 21528 624 18 22170 569a Sub-Total device text data bss dec hex 600 4 0 604 25c boot_printf.o 7404 204 0 7608 1db8 default_pager.o 432 128 0 560 230 def_pager_setup.o 3028 0 0 3028 bd4 file_io.o 1668 4 0 1672 688 load.o 13132 340 0 13472 34a0 Sub-Total boot_ufs text data bss dec hex 5044 28 0 5072 13d0 pmap.o 5044 28 0 5072 13d0 Sub-Total intel text data bss dec hex 460 0 0 460 1cc exec.o 260 4 0 264 108 fpu.o 0 96 0 96 60 gdt.o 56 0 0 56 38 hardclock.o 308 24 0 332 14c i386_init.o 420 4 0 424 1a8 init.o 440 0 0 440 1b8 io_emulate.o 132 0 0 132 84 io_map.o 4456 8332 0 12788 31f4 db_disasm.o 812 8 0 820 334 db_interface.o 1092 208 0 1300 514 db_trace.o 0 232 0 232 e8 ktss.o 0 32 0 32 20 ldt.o 104 4 0 108 6c loose_ends.o 616 92 0 708 2c4 pic.o 516 28 0 544 220 pit.o 1348 0 0 1348 544 pcb.o 172 0 0 172 ac phys.o 524 0 0 524 20c read_fault.o 44 4 0 48 30 setroot.o 3108 100 0 3208 c88 trap.o 80 0 0 80 50 bcopy.o 32 0 0 32 20 bzero.o 24 0 0 24 18 gcc.o 2664 2048 0 4712 1268 idt.o 140 0 0 140 8c interrupt.o 28 0 0 28 1c ntoh.o 232 52 0 284 11c spl.o 60 0 0 60 3c _setjmp.o 68 0 0 68 44 kdasm.o 1748 4360 0 6108 17dc locore.o 19944 15628 0 35572 8af4 Sub-Total i386 text data bss dec hex 616 1160 0 1776 6f0 autoconf.o 2564 96 0 2660 a64 blit.o 228 2080 0 2308 904 c765.o 2412 88 0 2500 9c4 com.o 60 644 0 704 2c0 conf.o 7532 64 0 7596 1dac hd.o 2960 36 0 2996 bb4 if_3c501.o 7128 56 0 7184 1c10 if_pc586.o 6632 120 0 6752 1a60 if_ns8390.o 76 4 0 80 50 iopl.o 9200 1448 0 10648 2998 kd.o 1184 20 0 1204 4b4 kd_event.o 1292 16 13 1321 529 kd_mouse.o 276 0 0 276 114 kd_queue.o 2692 0 0 2692 a84 m765drv.o 7472 36 0 7508 1d54 m765knl.o 0 80 0 80 50 pic_isa.o 1080 52 14 1146 47a rtc.o 53404 6000 27 59431 e827 Sub-Total i386at ---------------------------------------------------------------- The above views are my own, not necessarily those of my employer. Bill Webb (IBM AWD Palo Alto, Ca.), (415) 855-4457. UUCP: ...!uunet!ibmsupt!webb INTERNET: webb@ibminet.awdpa.ibm.com
jclark@sdcc6.ucsd.edu (John Clark) (02/22/91)
In article <1991Feb18.145707.26230@cbnews.att.com> rock@cbnews.att.com (Y. Rock Lee) writes: >In article <1991Feb16.002946.5711@zoo.toronto.edu> geoff@zoo.toronto.edu (Geoffrey Collyer) writes: >>Please note that the Mach ``micro-kernel'', at least as recently >>distributed, is claimed to exclude networking and file system code, + +245K of text is not "micro-kernel" at all in my opinion, especially when +all the networking and file system code are excluded. Also, it's a little +bit misleading to simply use the output from "size" to prove that UNIX I presumed that 'micro' meant 1) freee of un*x-ism and hence free of AT* license 2) included only task management and memory management. High level file system and other usual 'macro' kernel features where not included. As for 250k so what! Buy a 2 MegaBit ROM. -- John Clark jclark@ucsd.edu