-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, Sep 03, 2005 at 08:28:55PM +1000, Sam Couter wrote:
> telford <[EMAIL PROTECTED]> wrote:
> > If you do not want to go the whole hog and run a fully isolated virtual
> > machine then you MIGHT be able to recover SOME of the time but think about
> > a situation where you have swap-to-disk implemented as a user space task
> > and it crashes. Can you recover the situation? All memory on the entire
> > system is now in an untrustworthy state so you must find a way of cleanly
> > restarting every task -- most people call this a reboot.
>
> The point of a microkernel is that for the swap to become corrupted, the
> swap service must be buggy. It doesn't matter to the swap system how buggy
> the graphics or network drivers are, for example.
So if your graphics drivers crash out with a bad pointer was the error in
the graphics driver or was the memory corrupted by a bug in the swap service?
> Different tasks can even be using different virtual memory systems, so
> if one crashes then processes using the others are completely unaffected.
Except when those tasks interface with hardware and the hardware can do DMA
which includes storage devices, network cards, sound and graphics drivers.
Then there's anything that can access the i2c bus (and thus do things like
reprogram your CPU clock frequency), anything that can reprogram interrupt
delivery... Then there's all the various bridge machinations such as
opening an AGPGART window.
Yes, you do get memory protection and yes memory protection is a good start
but it certainly is no guarantee of safety. What I'm saying here is that
while a microkernel is a bit safer than a monolithic kernel... the microkernel
promises a lot more than it can deliver.
> > And because microkernel designs have been tried (e.g. MS-Windows NT)
> > and so far they have proven both slower and less stable.
>
> NT was never released as a microkernel, although that was the original
> plan. It has only ever pretended. NT's instability is mostly due to
> shoddy graphics and other drivers being loaded in kernel memory for
> performance reasons. In other words, the instability is due to *failing*
> to really be a microkernel.
>
> QNX was the first microkernel to demonstrate decent performance, and
> that came at the cost of flexibility and performance. More recent
> research has lead to more portable and flexible microkernels with high
> performace such as L4.
I think that's a bit of an unfair comparison because QNX never had the same
scope of applications that MS-Windows attempted to handle. QNX was written
by a very small team without even attempting to cope with things like
vendor-supplied Direct X drivers and the like.
> When Linux first came into existence,
> microkernels were still just a neat idea with a few big problems and
> were a long way from being proven.
And now microkernels are a little bit closer to being proven with a
long way to go... and still only a small hint that they might be a little
bit better than what we already have.
> The high cost of context switches and switching supervisor mode (ring
> zero) on and off on x86 makes things difficult for any microkernel.
Most of those problems are solved with SPARC machines which are easy
enough to get hold of. I notice that Sun never tried leaving their
basic BSD kernel design even though they designed the SPARC chips with
fast context switch in mind.
Besides all this, the real problem with current Linux kernels is not
that developers have problems tracking down bugs, or that they find the
bugs are difficult to fix. The real problem is that cutting-edge kernels
don't get tested enough to even detect the bugs that do exist. So many
people are perfectly happy with older kernels that even though the
number of Linux users is growing, the number of people testing new
kernels is getting smaller. Changing to a microkernel isn't going to
fix this either.
- Tel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iQIVAwUBQxzDfcfOVl0KFTApAQJlkw//Vv70gdv7lD17cxQ88tEKftktxSyd/59o
6EAqs4FNytZH/NSGB+UkcRQT8n8A/G1FV2bWbC+hHsk5QAYWQoAgrLdWMgNVfMkd
6zI0kAjd0l/85V0YyoNg5fZ+2nYjba9dEoXHtAtFWxNuA9jBt9SqCzc1L2146z1t
asiu5ZtsHsll4Bq5i9JCpcOpCxJ4yIMf1EsITlF0MBjeZCjsLu06Oql1FU31rRed
NzXnLvTHf2ozBY2AI23QfzVKrDxx4CJiFBXXedJUv0DzAEH/B6/DZ/ZOQB70ba+w
P6G2SSKDyIM+5esyZaXyPZrAv15OCitCkYFyKXxi8YUEgGvPuenDeI2e/6TJSbk8
RuUs2hXPTkcKaHbtNa4+jyrb0nrsMxS10hBgOXHHg/a08l9PEV359ZWuHELhOfIz
9dJutXryKS7etncBlRwKyRaBLq9e9t7rMd202G3fSRUJPYqs3pPqsRM/fttk1+5+
6CHMGJkthgTT5Le2TLTGynSyqSHGz0PnRPeNG4mBphHEd0kd2reIPpxulsDLOBjE
87qpn7I9//PCkKPM25j70pa6qGEwtOXh0UyvQsCNvgCuVlPaV0PWBSBF6M069n4u
HZDdNMaei2pyf9GN1MZaEFZ8SNaSfN60xJe+L8uO9AjKg0G4Em8vTLhmhVzowk0S
jHtGkPmpIhw=
=IISq
-----END PGP SIGNATURE-----
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
