Quote: Original post by flukusPerhaps. The benefits are questionably there, but are generally regarded as not worth the cost.
Isn't it meant to be a security feature that it doesn't even trust itself?
have you heard of HURD?
In a monolithic kernel, there's a large set of system calls -- typically around 200. You call the kernel to open a socket, write to a file, allocate a semaphore, poll a pipe, etc etc. Inside the kernel, there runs code that's assumed to be trustworthy, and gets free reign of the system. So, for example, a bug in a sound driver can corrupt your screen display, or worse, take the whole system down.
In a microkernel, subsystems (disk, sound, video, networking, etc) are typically split into user-level processes, and the basic kernel only does the bare minimum to make it possible to separate these processes from each other, and have them communicate with messaging. There might be a very small set of system calls that actually to into ring 0 -- say, no more than 20.
In a microkernel system, when you call sendto() on a socket, you end up sending a message to the networking process, which potentially in turn ends up sending a message to the network card driver process, or which just writes to a memory-mapped version of the hardware device. If there's a bad network card driver, it will crash the network card process (which can get re-started), rather than the system itself.
Sadly, system calls are much faster than message passing, so the performance of microkernels has never been all that great. All OS-es that want to optimize for performance end up going towards the monolithic kernel -- it's just so much faster. (I know from experience, having worked on BeOS for five years of my life)
In a microkernel, subsystems (disk, sound, video, networking, etc) are typically split into user-level processes, and the basic kernel only does the bare minimum to make it possible to separate these processes from each other, and have them communicate with messaging. There might be a very small set of system calls that actually to into ring 0 -- say, no more than 20.
In a microkernel system, when you call sendto() on a socket, you end up sending a message to the networking process, which potentially in turn ends up sending a message to the network card driver process, or which just writes to a memory-mapped version of the hardware device. If there's a bad network card driver, it will crash the network card process (which can get re-started), rather than the system itself.
Sadly, system calls are much faster than message passing, so the performance of microkernels has never been all that great. All OS-es that want to optimize for performance end up going towards the monolithic kernel -- it's just so much faster. (I know from experience, having worked on BeOS for five years of my life)
enum Bool { True, False, FileNotFound };
Quote: Original post by Alpha_ProgDes
most OSes are done in Assembly, C or a mixture. is it not?
Yep. Though you can replace the C parts with C++ (and using OOP) without sacrifying much (if any) performance. One reason that C is still the major part here is that C++ compilers were pretty crappy at the time most modern OSes were designed and implemented. Since a full-blown OS is not written during a cold winter, the existing code base is written in C. Apart from the fact that you can apply OOP techniques using C, too (which is done to a certain extend in most OSes anyway).
Yeah, monolithic kernels are much faster. Specially when you put bloated apps like Mozilla, Open Office or Gnome/KDE running on top of them... "Hey guys lets use this monolithic kernel which is 9% faster than the micro one so that we can waste all the speed on these great bloated applications"... So much for the speed eh?
Seriously, why do we keep doing things a la 70's? There is no reason to not use micro kernel operating systems on todays hardware, specially when you are running said bloated applications on top of the fast kernel which kill all your supposed speed advantage.
Hurd could be a good thing... too bad it comes from Mr Stallman...
Seriously, why do we keep doing things a la 70's? There is no reason to not use micro kernel operating systems on todays hardware, specially when you are running said bloated applications on top of the fast kernel which kill all your supposed speed advantage.
Hurd could be a good thing... too bad it comes from Mr Stallman...
so then how would you increase on a micro kernel OS?
is that even possible?
and how is Mozila, i'm assuuming Firebird, bloated?
is that even possible?
and how is Mozila, i'm assuuming Firebird, bloated?
October 15, 2004 05:09 PM
Quote: Original post by nectarine
Hurd could be a good thing... too bad it comes from Mr Stallman...
I suppose you don't use gcc, emacs or the entire bloody GNU toolset either then, eh?
Quote: Original post by Anonymous Poster
I suppose you don't use gcc, emacs or the entire bloody GNU toolset either then, eh?
Just because i don't like the guy that doesn't mean i don't like the tools.
I would just like to infuriate the rabid anti-Microsoft visitors by pointing out that Windows NT's kernel is a hybrid of monolithic and microkernel architectures. The kernel itself exists in a protected state, with the Executive acting as intermediary. What would be kernel functions in a monolithic design are actually Executive functions in NT, which then interfaces with the actual kernel. Windows NT is an object-oriented architecture, but it presents a simple procedural API.
Very impressive, and actually possessing more features blow-for-blow than your generic Unix.
Very impressive, and actually possessing more features blow-for-blow than your generic Unix.
Quote: Original post by Alpha_ProgDes
so then how would you increase on a micro kernel OS?
is that even possible?
and how is Mozila, i'm assuuming Firebird, bloated?
Well... considering that it takes about... 15 times longer to compile Mozilla Firebird compared to the Linux kernel... (~20 minutes versus ~5 hours)
(disregarding the fact that C++ compilers are slower)
October 15, 2004 05:34 PM
Quote: Original post by nectarineQuote: Original post by Anonymous Poster
I suppose you don't use gcc, emacs or the entire bloody GNU toolset either then, eh?
Just because i don't like the guy that doesn't mean i don't like the tools.
Why is it "the in thing" to hate RMS nowadays? What did he do that's so upsetting?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement