oversize kernels
brandon at tdi2.UUCP
brandon at tdi2.UUCP
Sat Feb 21 07:18:42 AEST 1987
Quoted from <13451 at sun.uucp> ["Re: UUCP Port Turnaround (==> Unix Kernel hacks)"], by guy%gorodish at Sun.COM (Guy Harris)...
+---------------
| >etc. What's the old kernel up to these days, a meg and a half or so?]
|
| gorodish$ size /vmunix
| text data bss dec hex
| 445120 77784 120348 643252 9d0b4
|
| Try again. (This is a kernel with lots of bits under development,
| too, so a lot of that stuff will go away eventually.)
+---------------
$ size /unix
169594 + 15206 + 144092 = 328892
Why, if the BSD kernel is so small, is the System V Release 2 kernel half
the size of it?
+---------------
| >My guess, Guy, is that the person in question was referring to the
| >the _commonly_ held belief that the Berkeley kernel is too large
| >and seems to be growing without bounds.
|
| There are lots of commonly held beliefs; the fact that a belief is
| commonly held does not necessarily mean that it is true.
|
| As for singling out the Berkeley kernel, I shall point out that I
| just did a "size" on "/unix" on a 3B2 around here, and it was about
| 800KB.
+---------------
AT&T is getting the BSD disease. It's called "layers", in this case.
HARDWIRED TERMINALS IN THE KERNEL, FOR GHOD'S SAKE? See above for the
size of a good, sane SVR2 kernel.
I've hacked quite a bit into this system. In user mode. It's not quite
4BSD yet, but then we have no need for networking. (To the people who will
immediately compare this posting to my posting asking for system load help
and say "Aha!": Wrong. It's 18 users running RM/COBOL and/or UNIFY that
brings tdi2 to its knees.)
++Brandon
--
``for is he not of the Children of Luthien? Never shall that line fail, though
the years may lengthen beyond count.'' --J. R. R. Tolkien
Brandon S. Allbery UUCP: cbatt!cwruecmp!ncoast!tdi2!brandon
Tridelta Industries, Inc. CSNET: ncoast!allbery at Case
7350 Corporate Blvd. INTERNET: ncoast!allbery%Case.CSNET at relay.CS.NET
Mentor, Ohio 44060 PHONE: +1 216 255 1080 (home) +1 216 974 9210
More information about the Comp.unix.questions
mailing list