Criticism ... synthesis?
Mike Prince
mprince@crl.com
Sat, 17 Dec 1994 16:39:55 -0800 (PST)
This is going to be a very short reply...
On Sat, 17 Dec 1994, Francois-Rene Rideau wrote:
> > 1. You use "monolithic" in criticism of an idea that is
> > straightforward, and instead postulate a more complex system!
> Computing *is* complex anyway. I propose that the system directly
> accepts complexity, instead of requiring other systems to be built
> on top of it to handle that (which would make our OS useless).
No.
> > 2. "hugeware" ?
> > My initial statement (and it appears in Mike's compilation of our
> > goals)
> > was that the core code should be +- 20 lines (with everything stemming
> > from this). Yours is obviously a completely new interpretation of the
> > word "huge"!
> Mike was suggesting that builtin in our OS "kernel" would be a 3-D
> engine, BitBlt routines, et al ! And that any asm things possibly needed
> should be inside our system.
No. All those are drivers outside the kernel. The kernel will be under 20K.
> > 3. "centralised". This is again unfair. Sharing common characteristics
> > is not the same as being centralised.
[snip]
> That's the flaw of microkernel. You don't remove centralization by
> reducing the size of the kernel, but by eliminating the kernel.
> If you want microkernels, go VSTa, Mach, or Chorus !!!
A kernel is core system code that manages things. Fare's version of the
HLL will have a kernel, but he doesn't want it called that. He justifies
it isn't a kernel because all parts can be upgraded.
But there IS still a kernel. Fare, just admit it! It makes discussion
amongst us easier, and with outsiders. Instead of putting down other
kernel architectures, work on building up your own! Tell me how your
reloadable module system would work to maintain "kernel" resources.
Remember, someone manages memory (read kernel), someone services
interrupts (again, probably the kernel gets the first crack at it),
someone does contect switches (absolutely the kernel).
OK, so you say you fragment memory and have each object maintain it's owm
memory management, but still, you have a head honcho involved in the
first level distribution.
I've gone on too long. Please give me details of your own, not general
criticisms of others.
I'm not even bothering going on any further. Check my next post for a
response to JVs.
Mike