Linked by Thom Holwerda on Sun 16th Apr 2006 15:36 UTC
Permalink for comment 115292
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
More News »
Sponsored Links



Member since:
2005-11-16
Some notes:
The "clock" is probably a source of periodic interrupt used by the scheduler for pre-emptive task switching and timing (things like a "sleep()" function). It probably has nothing to do with "time and date". Because the scheduler relies on this clock (and everything else relies on the scheduler instead of this clock), building support for it into the microkernel is a very sane thing to do.
A micro-kernel is not necessarily "fail-safe". For example, if the hard disk driver crashes then you'll loose all of the data stored in swap space, and having a micro-kernel won't help to retrieve it. Another example would be the virtual file system - if it crashes then any software that was relying on it will loose their open file handles, etc. The same applies to everything that retains "client state". With a lot of work a micro-kernel can be more "fail-safe", but you need systems in place to take care of each type of failure. Without these extra systems it's not much better than a monolithic kernel (of course "protection" is a different subject).