OSDev.org

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.

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.

berkus wrote:

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.

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.

I'll check it.

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.

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?

Hi,

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?

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.

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

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'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.

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.

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.

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 source of an exokernel? I've searched in the MIT webpage but I haven't found it.

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: The exokernels, in general, are more efficient or less than a monolithic one? And than an hibrid?

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.

Love4Boobies wrote:exokernels are not a type of kernel, they are a type of kernel interface.

...whatever that means.

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?

Rusky wrote:...whatever that means.

This shows you refuse to learn what you probably will need to know.

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.

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.

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.