Modularity vs monolithic images

Cees de Groot cg at cdegroot.com
Mon Sep 3 07:19:09 UTC 2001


Roger Vossler <rvossler at qwest.net> said:
>    While modularity usually gains a certain amount of flexibility, the
>price paid is a big hit in performance. Although I'm not sure about this,
>is not the Linux kernel monolithic as opposed to various Mach-based
>implementations of UNIX?
>
Nes (or Yo, whatever). The Linux *core* kernel is a tiny little blazingly
fast monolithic beast. But then you can attach all sorts of goodies to it,
called modules - device drivers, network protocols, system watchdogs,
graphics interfaces, whatever. I think it's a best-of-both-worlds
solution, because the core is still statically configurable - read
recompile - for special purposes (so you can still take stuff away for
really small machines) while the run-of-the-mill Linux kernel will work
for 95% of the uses because it will be adorned with modules to shape it for
the particular task at hand. 

To me, sounds like a perfect model for the Squeak VM. Dynamically loaded
objects aren't any slower than statically linked librarys on the OSes I 
know, and on the Smalltalk level the issue is non-existant anyway. 

Mach is the far end of the spectrum monolithic<->microkernel. As happens so
often, it's an interesting theoretical idea, but in practice more conventional
approaches turn out to work at least just as well. There's an interesting
discussion on this topic between Linus Torvalds and Andrew Tanenbaum
(http://www.oreilly.com/catalog/opensources/book/appa.html). Despite
Tanenbaums' outstanding credentials, most people think that
then-still-undergrad Torvalds won :-). Those where the days...

(actually, I think there was even a 'farther end', Amoeba - an
object-oriented research OS developed at the Free University of Amsterdam
in the '80s)

-- 
Cees de Groot               http://www.cdegroot.com     <cg at cdegroot.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B
Building software is like quantum mechanics: you can predict what it
will do, or when it will be ready -- but not both.




More information about the Squeak-dev mailing list