Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!oleane!tank.news.pipex.net!pipex!swrinde!cs.utexas.edu!news.cs.utah.edu!news.cc.utah.edu!news.caldera.com!park.uvsc.edu!usenet
From: Terry Lambert <terry@cs.weber.edu>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: The Future of FreeBSD...
Date: 21 Jul 1995 01:24:41 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 64
Message-ID: <3umvkp$c8l@park.uvsc.edu>
References: <3uktse$d9c@hal.nt.tuwien.ac.at> <Ek3eKzC00ggL1EveAS@cs.cmu.edu>
NNTP-Posting-Host: hecate.artisoft.com
Matthew.White@cs.cmu.edu wrote:
]
] To my mind, the microkernel is the way of the future. With increasingly
] diverse processor architectures available, this is one technology that
] will keep things manageable. With microkernels, a development effort
] can proceed with far fewer individuals because the maintainance cost of
] additional platforms is minimal. Thus we can have a situation better
] suited for small businesses and public domain developers. Instead of
] large numbers of mediocre programmers producing huge amounts of mediocre
] code (as many firms seem to do), we have a small number of excellent
] programmers producing a smaller, but functionally equivelant, amount of
] excellent code.
A microkernel is not the only possible hardware abstraction
mechanism (the main benefit you cite here), and the Mach
microkernel is not the best possible microkernel for a number
of reasons. Chorus (a proprietary microkernel implementation
being used for advanced projects by Novell) addresses a number
of issues in Mach, most notably causing a great reduction in
the message overhead and the amount of protection domain
crossing that goes on.
Nevertheless, there are many projects that in fact abstract
the hardware sufficiently to obviate the need for that part
of the microkernel's capability. SVR4.2 ES/MP is one example
and NT is another.
] There's a strong performance argument, because microkernels seem
] inherently slower. It is my opinion that advantages outlined above
] heavily outweigh this, especially when one considers the high
] performance offered by new processors of today. There will come a time,
] soon, when the added stability and feature sets of microkernel OSes will
] dominate.
The problem with tis argument is that I can always run faster
by writing closer to the glass, and faster is aways better no
matter how fast you are already running. 8-).
] What does this have to do with FreeBSD? Not a thing that I can see. My
] understanding of FreeBSD is that it was designed to run on the Intel
] platform, period. With this design goal in mind, what is the advantage
] of sacrificing speed to have an ultraportable OS? Especially when you
] consider that Intel processors are relatively slow when compared to the
] RISC processors available.
Your understanding of the design of FreeBSD is flawed. It is
intended to be portable to multiple platforms. That it is not
already distributed on non-Intel platforms is a portation and
political issue, not a design issue.
The sacrafice of speed is only necessary if you buy into the
Microkernel mechanism for hardware abstraction, and then that
is largely irrelevent unless you choose a particular microkernel
technology that exhibits the limitations you have outlined.
That there is not a non-proprietary technology microkernel for
use in abstracting the hardware interface is a seperate problem.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.