About exokernels...
About exokernels...
Is there any book about exokernels (like the Tannenbaum's one but changing microkernel for exokernel)? I've searched but I haven't found anything.
Is there any source of an exokernel? I've searched in the MIT webpage but I haven't found it.
The exokernels, in general, are more efficient or less than a monolithic one? And than an hibrid?
Thanks and sorry my English.
Is there any source of an exokernel? I've searched in the MIT webpage but I haven't found it.
The exokernels, in general, are more efficient or less than a monolithic one? And than an hibrid?
Thanks and sorry my English.
Re: About exokernels...
A lot of the exokernel research has been focused on how the design makes things faster. Removing unnecessary abstractions can speed things up a lot, and there have been some real applications written that are much faster than their counterparts on monolithic systems.
Re: About exokernels...
I'll check it.berkus wrote:I won't insult your googling skills and only tell there's an accessible CVS server with the sources as well as a downloadable tarball of the latest release.MIT developed two exokernel-based operating systems, using two kernels: Aegis, a proof of concept with limited support for storage, and XOK, which applied the exokernel concept more thoroughly.
-
- Member
- Posts: 595
- Joined: Mon Jul 05, 2010 4:15 pm
Re: About exokernels...
I find the exokernel definition and microkernels definition ambigous. There is no clear definition between a monolithic kernel and a microkernel either. There is everything in between these definitions.
Re: About exokernels...
That is what I've read but I have not actually understood what that would mean programming wise. I'd like to know how this resource basically works and what exactly is hardware multiplexing? I think I know but I might be totally wrong. Anyone care to explain?
Fudge - Simplicity, clarity and speed.
http://github.com/Jezze/fudge/
http://github.com/Jezze/fudge/
Re: About exokernels...
Hi,
The first problem is permissions (user space code usually doesn't have access to most things). The second problem is that different kernels will fight for the same resources (e.g. multiple kernels trying to modify/use the same RAM, or disk sectors, or whatever at the same time). To solve both of these problems you want something to control access to resources and ensure orderly sharing of resources. That is what the exo-kernel does.
Basically you end up with the exo-kernel controlling access to resources, and each process using a separate instance of a "monolithic kernel library" (or "libOS"), where (in theory) different processes could use a different "libOS". However, in practice, nobody really wants to mess about with the internals of the "libOS" just to make their tetris clone half a cycle faster, and for the rare cases that it's worthwhile it's more worthwhile to have an OS dedicated to that purpose (e.g. an Oracle SQL server with the OS and hardware designed/tuned specifically SQL); so it's extremely rare for anyone (outside of researchers) to take advantage of the theoretical performance advantages in practice.
The main practical benefit of exo-kernels is extensibility - for example you could write the exo-kernel and provide a default/native "libOS", then someone else could implement a "*nix clone libOS", and someone else could write "Windows clone libOS".
Cheers,
Brendan
Imagine if you wanted to run several different monolithic kernels at the same time (on the same computer). You might implement each different monolithic kernel as a library, and each process could be linked to whatever kernel it felt like using. Of course this is going to cause a few problems.Jezze wrote:That is what I've read but I have not actually understood what that would mean programming wise. I'd like to know how this resource basically works and what exactly is hardware multiplexing? I think I know but I might be totally wrong. Anyone care to explain?
The first problem is permissions (user space code usually doesn't have access to most things). The second problem is that different kernels will fight for the same resources (e.g. multiple kernels trying to modify/use the same RAM, or disk sectors, or whatever at the same time). To solve both of these problems you want something to control access to resources and ensure orderly sharing of resources. That is what the exo-kernel does.
Basically you end up with the exo-kernel controlling access to resources, and each process using a separate instance of a "monolithic kernel library" (or "libOS"), where (in theory) different processes could use a different "libOS". However, in practice, nobody really wants to mess about with the internals of the "libOS" just to make their tetris clone half a cycle faster, and for the rare cases that it's worthwhile it's more worthwhile to have an OS dedicated to that purpose (e.g. an Oracle SQL server with the OS and hardware designed/tuned specifically SQL); so it's extremely rare for anyone (outside of researchers) to take advantage of the theoretical performance advantages in practice.
The main practical benefit of exo-kernels is extensibility - for example you could write the exo-kernel and provide a default/native "libOS", then someone else could implement a "*nix clone libOS", and someone else could write "Windows clone libOS".
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: About exokernels...
Ok that cleared it up.
I though hardware multiplexing had to do with memory mapped memory guarded through paging. If I may explain...
On most architectures hardware has memory mapped regions. What I thought was that each libOS would have access to this area but not at the same time meaning the pages for that resource would only be accessible by one libOS at a time. A sort of "page-lock" or "hardware-resource-lock" if you like. A libOS trying to access this area during a lock set by another libOS would result in a page fault and be suspended until the other libOS was finished.
I imagine this could work for ordinary processes in a normal kernel as well so I really didn't get the difference but now I know this had nothing to do with it.
I though hardware multiplexing had to do with memory mapped memory guarded through paging. If I may explain...
On most architectures hardware has memory mapped regions. What I thought was that each libOS would have access to this area but not at the same time meaning the pages for that resource would only be accessible by one libOS at a time. A sort of "page-lock" or "hardware-resource-lock" if you like. A libOS trying to access this area during a lock set by another libOS would result in a page fault and be suspended until the other libOS was finished.
I imagine this could work for ordinary processes in a normal kernel as well so I really didn't get the difference but now I know this had nothing to do with it.
Fudge - Simplicity, clarity and speed.
http://github.com/Jezze/fudge/
http://github.com/Jezze/fudge/
- Colonel Kernel
- Member
- Posts: 1437
- Joined: Tue Oct 17, 2006 6:06 pm
- Location: Vancouver, BC, Canada
- Contact:
Re: About exokernels...
I've never understood what problem exokernels are trying to solve. Practically speaking they seem to offer the same benefits as virtualization, possibly with better performance.
Top three reasons why my OS project died:
- Too much overtime at work
- Got married
- My brain got stuck in an infinite loop while trying to design the memory manager
Re: About exokernels...
Exokernels allow individual applications to use their own better-suited abstractions, e.g. over things like disk blocks, rather than going through the file system, or the API that an app from another OS is written to. You could do that with virtualization if you wanted to spin up an entire OS for each of those applications, but that makes a lot of things difficult- scheduling for processor time and IO, IPC and sharing data, libraries, configuration, etc. not to mention a lot of duplication of data and work.
With an exokernel, those applications are instead running natively in the same kernel, where they can be much more integrated into the system. Instead of having a performance overhead from virtualization, applications can run faster than before. Sometimes even binary emulation is faster than the original system.
With an exokernel, those applications are instead running natively in the same kernel, where they can be much more integrated into the system. Instead of having a performance overhead from virtualization, applications can run faster than before. Sometimes even binary emulation is faster than the original system.
- Love4Boobies
- Member
- Posts: 2111
- Joined: Fri Mar 07, 2008 5:36 pm
- Location: Bucharest, Romania
Re: About exokernels...
That's ridiculous. That's like asking about a book on FAT. What's wrong with the papers and theses on the MIT webiste?arming wrote: Is there any book about exokernels (like the Tannenbaum's one but changing microkernel for exokernel)? I've searched but I haven't found anything.
The homepage of the website you are referring to only has a couple of paragraphs and you were unable to find it? Congratulations, you failed as a human being.arming wrote: Is there any source of an exokernel? I've searched in the MIT webpage but I haven't found it.
Let me rephrase this for you: "I have done absolutely no research and have no intention to do so but I am hoping someone on this forum will tell me how to be the best OS developer in the world in one paragraph." To get back to the real question, exokernels are not a type of kernel, they are a type of kernel interface.arming wrote: The exokernels, in general, are more efficient or less than a monolithic one? And than an hibrid?
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
[ Project UDI ]
Re: About exokernels...
...whatever that means.Love4Boobies wrote:exokernels are not a type of kernel, they are a type of kernel interface.
- Love4Boobies
- Member
- Posts: 2111
- Joined: Fri Mar 07, 2008 5:36 pm
- Location: Bucharest, Romania
Re: About exokernels...
You don't know the meaning of the word interface? Or did you expect me to be redundant and explain that I was talking about the way applications interface with the hardware directly (while being protected from each other by the kernel) rather via the usual abstractions even though you already did that in a previous post?
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
[ Project UDI ]
Re: About exokernels...
This shows you refuse to learn what you probably will need to know.Rusky wrote:...whatever that means.
That means you will end up not knowing what you are looking for because you are being stubborn and not taking in what is being given to you.
That means you are going to keep asking questions.
Change your ways. Take that as friendly info, you wont survive on this forum if you do not.
- Love4Boobies
- Member
- Posts: 2111
- Joined: Fri Mar 07, 2008 5:36 pm
- Location: Bucharest, Romania
Re: About exokernels...
I don't think that was the problem. I think he was just trying to correct me, which is not really a bad thing. It's just that this time I wasn't being verbose on purpose.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
[ Project UDI ]
Re: About exokernels...
My point was that "kernel type" vs "kernel interface type" is a meaningless distinction. The kernel interface is pretty integral to the kernel's design.