About exokernels...

[Brendan]

Hi,

Lets honour your request and make your life difficult in return:

No it's not that simple. Answer these questions:
[*]What actually determines who gets CPU time when (each individual process or the kernel)?

The end user. It chooses which tasks the computer should do and therefore what the computer must put time spending.

Wrong. The end user only starts tasks and never says when their actually given CPU time.

[*]What actually determines when to read data, whether it be a high priority read or a prefetch, (each individual process or the kernel)?

The user and the process. The kernel can't know what to read until it is explicitly told to. If there's no file loaded ever, the kernel has no clue what to prefetch either.

Wrong. "What" is always different to "when", "why" and "how". A process might say what to read, but doesn't determine when (or how, that's the driver's job).

[*]What actually determines when a CPU should enter a power management state (each individual process or the kernel)?

When the user is around or not.

Wrong. When the user is around, but there's 16 CPUs that are mostly doing nothing most of the time (waiting for the user to press a key) it makes sense for kernel to send 8 or more CPUs into a power saving state. Alternatively, when the user is not around the OS should be updating software, de-fragmenting disk and/or serving web pages. Mostly, power management depends on average CPU usage (and average CPU usage may or may not be effected by user presence), and only the kernel really knows about average CPU usage.

[*]What actually determines when load should be migrated between CPUs (each individual process or the kernel)?

The end user?

[/quote]

Wrong. The end user only knows when they want load to be migrated (and don't know when load should be migrated); and typically can't "baby sit" the OS and make changes in real time anyway. Of course in theory it's possible for "what the user wants" and "what should happen" to coincide (in a "stopped clock is right twice a day" way); but in practice it's hard enough just finding a normal user that, when asked to point at their computer, doesn't point at their monitor.

Total score for this quiz: 0/5. Better luck next time...


Cheers,

Brendan

[Combuster]

I'm glad you just demonstrated that you are allowed to use a form of argumentation that I'm not allowed to use.

[dschatz]

Hi,

This must be what makes "exo-kernel" so magical - it exists in 2 mutually exclusive states at the same time (possibly in some parallel universe full of pixies and unicorns), where processes are in control and the kernel isn't but at the same time the kernel is in control and processes aren't.

And you missed that I never mentioned that the boss was not in charge - the tasks of the boss simply changed. The boss is in charge of keeping things running, the tasks are in charge of how they use the resources given. Therefore they are both in charge of something. It is that simple.

No it's not that simple. Answer these questions:

• What actually determines who gets CPU time when (each individual process or the kernel)?
• What actually determines when to read data, whether it be a high priority read or a prefetch, (each individual process or the kernel)?
• What actually determines when a CPU should enter a power management state (each individual process or the kernel)?
• What actually determines when load should be migrated between CPUs (each individual process or the kernel)?

From what Rusky is saying; the kernel is what actually determines all of these things, and the processes themselves have no direct control over any of it (and only have indirect control via. suggestions/hints that the kernel is free to ignore and/or postpone). This makes perfect sense as the kernel is the only thing that has the information needed to make efficient global optimisations - each process is isolated and shouldn't care how many other processes are trying to use the CPU/s or read data from which devices or whatever else. Basically, the kernel is in charge and not the processes, and this makes perfect sense.

Now let's draw some diagrams:

Code: Select all

    _____________
   |             |
   |  Kernel and |
   |    Drivers  |
   |_____________|
        |
        | Kernel API
        |
        |   CPL=0
--------|-------------
        |   CPL=3
        |
    ____|________
   |             |
   | Library     |
   |_____________|
   |             |
   |  Process    |
   |_____________|

For this diagram, each process can have a different library (that uses the kernel API), where each different library can provide a different interface to the process (e.g. a POSIX interface, a Win32 interface, etc). Is this a diagram of a monolithic kernel (e.g. where the library is typically a standard C/C++/POSX library, but may not be), or is this a diagram of an exo-kernel?

Let's assume this is a diagram of a monolithic kernel. The Kernel API could be anything (it mostly only exists to keep the library happy; although it is possible for a process to use the bare kernel API without any library). For example, the kernel API could provide higher level abstractions and include things like "fopen()" and "malloc()" (where the library is a very minimal layer). The kernel API could also provide lower level abstractions - for example, it might only provide "open()" and "sbrk()" where the library has to implement "fopen()" and "malloc()" on top. For another example, the kernel API might provide extremely low level abstractions - e.g. it might only expose raw blocks and pages, where the library has to implement "open()" and "fopen()", and "sbrk()" and "malloc()" on top of that. None of this changes the fact that it's still a monolithic kernel - it's just a sliding scale of from "very high level kernel API abstractions" to "very low level kernel API abstractions". If fact nothing really prevents a monolithic kernel's API from providing multiple levels of abstraction at the same time - e.g. it could provide very high level abstractions in addition to providing a very low level abstractions.

Now; think about a monolithic kernel that provides a very low level abstractions via. its kernel API; and tell me how that is different to an exo-kernel. It's impossible for an exo-kernel to do anything that a monolithic kernel can't do, because they're essentially exactly the same thing.

The real question here is whether a monolithic kernel's API should provide very high level abstractions, or very low level abstractions, or something in between, or a mixture of high and low level abstractions. The most likely answer to this is "something in between" - if it made sense to provide very low level abstractions then all of the existing monolithic kernels would be providing those low level abstractions already (possibly in addition to their existing higher level abstractions, for the sake of compatibility); or at a minimum they'd be evolving towards lower level abstractions; so that they can give the "massive number of people" that write their own library (and don't just use the system's standard C/C++/POSIX library) a lot more flexibility.

Of course I'm been a little sarcastic - some people actually do write their own library instead of just using the system's standard C/C++/POSX library. Examples of this are the Wine project (implementing the Win32 API on *nix systems) and Microsoft's POSIX subsystem (implementing a standard C/C++/POSX library on Windows). It's not like you need very low level abstractions for this.

So what are the benefits of having very low level abstractions? The main benefit is, if you're a researcher and not writing a "real world OS" and don't need to care about malicious code, or compatibility, or features that people have grown to expect (e.g. like your web server being able to files stored on an NFS file system); then you can make it seem like low level abstractions provide better performance in some cases without acknowledging the fact that the sacrifices you've made to gain that extra performance are unlikely to be practical in a real OS.


Cheers,

Brendan

I think its helpful to look at exokernel + library OS as an orthogonal design decision to microkernel vs monolithic kernel. An exokernel is (as you state) all about providing low level abstractions so that user level specialization can occur. You can provide these low level abstractions using a monolithic design (as most exokernels have), or using a microkernel design (with drivers in userspace, per-application filesystems in separate address spaces, etc.). Microkernel vs monolithic kernel is about how you structure the rings of protection; exokernel is about the interfaces the system provides to it's applications.

[Rusky]

[*]What actually determines who gets CPU time when (each individual process or the kernel)?

The kernel provides CPU time, because the exokernel's job is to "securely multiplex hardware."

[*]What actually determines when to read data, whether it be a high priority read or a prefetch, (each individual process or the kernel)?

Individual processes issue read schedules (for regular and prefetch reads) that are merged by the kernel.

[*]What actually determines when a CPU should enter a power management state (each individual process or the kernel)?

The kernel "securely multiplexes hardware." It's not really to the advantage of any individual application to care about PM.

[*]What actually determines when load should be migrated between CPUs (each individual process or the kernel)?[/list]

Individual applications can request specific CPUs, the kernel, "securely multiplexing hardware," hands out CPU time, and also notifies the applications so they can decide what to do with the particular CPU they're running on.

Let's look at some more questions:

• Who decides which disk blocks to read, write, or allocate, when and where? Can you do a zero-touch, all-files-at-once asynchronous-I/O-based cp?
• Who decides which physical pages to swap out, discard, or otherwise free (and how to do so)? Can you use an algorithm other than LRU to decide, depending on your application?
• Who decides how to handle application-caused interrupts/exceptions? (signal handlers decide too much performance-wise)
• Who decides the internals of the network stack? Is it the kernel, possibly providing zero-copy interfaces like sendfile/splice, or the applications, who can implement sendfile-like operations for even non-file situations? Is it the kernel, providing lots of ioctls and flags for things like delayed TCP ack, or is the application, who can just do it however is optimal (e.g. also combining the fin packet with the last data packet)? Is it the kernel, who has separate TCP retransmission buffer, or the application, who can retransmit directly from its own buffers?
• Who pulls the data out of/puts the data in network packets? (Linux packet mmap is a very exokernel-like interface) Can you implement precomputed checksums for zero-touch disk cache->network packet transmission? Can you discard rather than copy packets, skip checksum verification, etc. for stress testing tools? Can you implement a zero-overhead TCP/IP forwarder for e.g. a network load balancing algorithm?

Of course you could put hints and options for these in the kernel, but patching the kernel, especially to change interfaces, is a lot more work than just doing it yourself in userspace. It's also a lot less future-proof.

The Xok benchmarks may be missing some features (although I'm still not sure what, the Cheetah vs Harvest certainly isn't), but it goes both ways- Cheetah implements several features not present in OpenBSD. There's also a slightly newer paper from 2002: http://pdos.csail.mit.edu/papers/exo:tocs.pdf It has a few more examples of exokernel-specialized applications. They also add IIS/NT to their Cheetah benchmark, which does use zero-copy, and which even their baseline Socket/Xok server outperforms on slower hardware.

For another example, the kernel API might provide extremely low level abstractions - e.g. it might only expose raw blocks and pages, where the library has to implement "open()" and "fopen()", and "sbrk()" and "malloc()" on top of that. None of this changes the fact that it's still a monolithic kernel - it's just a sliding scale of from "very high level kernel API abstractions" to "very low level kernel API abstractions". If fact nothing really prevents a monolithic kernel's API from providing multiple levels of abstraction at the same time - e.g. it could provide very high level abstractions in addition to providing a very low level abstractions.

When you provide those "very low level kernel API abstractions" and still protect applications from each other, you are an exokernel. At that point, you may as well move the high level abstractions out of the kernel to 1) make them more easily modified.debugged, 2) reduce system call overhead, and 3) reduce the surface kernel attackers can target.

if it made sense to provide very low level abstractions then all of the existing monolithic kernels would be providing those low level abstractions already (possibly in addition to their existing higher level abstractions, for the sake of compatibility); or at a minimum they'd be evolving towards lower level abstractions; so that they can give the "massive number of people" that write their own library (and don't just use the system's standard C/C++/POSIX library) a lot more flexibility.

They are. Linux graphics is one example. Obviously, as you mention, compatibility is a concern. I would add momentum- nobody wants to overhaul the Linux file systems and network stack to run in user space, they simply weren't designed for that.

Of course I'm been a little sarcastic - some people actually do write their own library instead of just using the system's standard C/C++/POSX library. Examples of this are the Wine project (implementing the Win32 API on *nix systems) and Microsoft's POSIX subsystem (implementing a standard C/C++/POSX library on Windows). It's not like you need very low level abstractions for this.

So what are the benefits of having very low level abstractions? The main benefit is, if you're a researcher and not writing a "real world OS" and don't need to care about malicious code, or compatibility, or features that people have grown to expect (e.g. like your web server being able to files stored on an NFS file system); then you can make it seem like low level abstractions provide better performance in some cases without acknowledging the fact that the sacrifices you've made to gain that extra performance are unlikely to be practical in a real OS.

Of course you don't need low-level abstraction to do that, but without low-level abstraction, you have to translate between e.g. Win32 and POSIX, which is slower (see also Cygwin). That also doesn't mean you have to go all the way to the bottom just because that's what the kernel exposes. For example, Cheetah could still load disk blocks from local or NFS file systems using a VFS library, which would have no effect on optimizations like TCP retransmission, packet merging, checksum precomputation, etc.

[Brendan]

Hi,

[*]What actually determines who gets CPU time when (each individual process or the kernel)?

The kernel provides CPU time, because the exokernel's job is to "securely multiplex hardware."

So, same as a monolithic kernel.

[*]What actually determines when to read data, whether it be a high priority read or a prefetch, (each individual process or the kernel)?

Individual processes issue read schedules (for regular and prefetch reads) that are merged by the kernel.

So, same as a monolithic kernel (using POSIX asynchronous IO).

[*]What actually determines when a CPU should enter a power management state (each individual process or the kernel)?

The kernel "securely multiplexes hardware." It's not really to the advantage of any individual application to care about PM.

So, same as a monolithic kernel.

[*]What actually determines when load should be migrated between CPUs (each individual process or the kernel)?[/list]

Individual applications can request specific CPUs, the kernel, "securely multiplexing hardware," hands out CPU time, and also notifies the applications so they can decide what to do with the particular CPU they're running on.

There's no reason a monolithic kernel can't do this (but most don't/won't because it's much less able to adapt quickly/dynamically and has higher overhead).

Let's look at some more questions:

Only the designer of a monolithic kernel can answer these questions for their monolithic kernel. It's not like there's a set "all monolithic kernels must be like *nix and work in similar ways with similar abstractions" rule or anything.

The Xok benchmarks may be missing some features (although I'm still not sure what, the Cheetah vs Harvest certainly isn't), but it goes both ways- Cheetah implements several features not present in OpenBSD. There's also a slightly newer paper from 2002: http://pdos.csail.mit.edu/papers/exo:tocs.pdf It has a few more examples of exokernel-specialized applications. They also add IIS/NT to their Cheetah benchmark, which does use zero-copy, and which even their baseline Socket/Xok server outperforms on slower hardware.

A research paper that suggests existing monolithic kernels should implement broken networking with no security at all for the sake of performance (that does not say that exo-kernels are necessary for this, or that exo-kernels are good in any way whatsoever)?

Note that the paper says it compared Xok/ExOS to OpenBSD 2.2 (from 1997), and Microsoft's IIS version 2 (1996), and 200 MHz Pentium Pro CPUs (from 1995). The paper might be more recent (the copyright says 2002) but even if the paper is more recent I'd be willing to bet that their benchmarks were taken "as is" from old research done in 1997 and were not repeated on software and hardware from this century.

For another example, the kernel API might provide extremely low level abstractions - e.g. it might only expose raw blocks and pages, where the library has to implement "open()" and "fopen()", and "sbrk()" and "malloc()" on top of that. None of this changes the fact that it's still a monolithic kernel - it's just a sliding scale of from "very high level kernel API abstractions" to "very low level kernel API abstractions". If fact nothing really prevents a monolithic kernel's API from providing multiple levels of abstraction at the same time - e.g. it could provide very high level abstractions in addition to providing a very low level abstractions.

When you provide those "very low level kernel API abstractions" and still protect applications from each other, you are an exokernel. At that point, you may as well move the high level abstractions out of the kernel to 1) make them more easily modified.debugged, 2) reduce system call overhead, and 3) reduce the surface kernel attackers can target.

No; it makes you a monolithic kernel that implemented some lower level abstractions where it's beneficial in practice (rather than merely beneficial in some researcher's synthetic "apples to oranges" benchmark).


Cheers,

Brendan

[Rusky]

Individual applications can request specific CPUs, the kernel, "securely multiplexing hardware," hands out CPU time, and also notifies the applications so they can decide what to do with the particular CPU they're running on.

There's no reason a monolithic kernel can't do this (but most don't/won't because it's much less able to adapt quickly/dynamically and has higher overhead).

Actually it has less overhead. Instead of picking a thread and restoring its state to the newly chosen CPU, the kernel just jumps to a fixed entry point in the process, which can then make the thread decision itself and restore exactly the state it needs. So say you want to implement a different model from traditional multithreading- which has more overhead? Emulating that model on top of kernel threads/processes, or just jumping straight into the code for that model as soon as a processor is available?

When you provide those "very low level kernel API abstractions" and still protect applications from each other, you are an exokernel. At that point, you may as well move the high level abstractions out of the kernel to 1) make them more easily modified/debugged, 2) reduce system call overhead, and 3) reduce the surface kernel attackers can target.

No; it makes you a monolithic kernel that implemented some lower level abstractions where it's beneficial in practice (rather than merely beneficial in some researcher's synthetic "apples to oranges" benchmark).

Now you're just arguing over definitions. "Exokernel" is defined as a kernel that avoids abstraction and instead provides low-level interfaces. The motivation doesn't matter- it's still using exokernel principles, and if it's a dominant characteristic of your design, it's an exokernel. I honestly don't care what you call it, as long as you understand what I mean when I say it.

[Owen]

The Xok benchmarks may be missing some features (although I'm still not sure what, the Cheetah vs Harvest certainly isn't), but it goes both ways- Cheetah implements several features not present in OpenBSD. There's also a slightly newer paper from 2002: http://pdos.csail.mit.edu/papers/exo:tocs.pdf It has a few more examples of exokernel-specialized applications. They also add IIS/NT to their Cheetah benchmark, which does use zero-copy, and which even their baseline Socket/Xok server outperforms on slower hardware.

A research paper that suggests existing monolithic kernels should implement broken networking with no security at all for the sake of performance (that does not say that exo-kernels are necessary for this, or that exo-kernels are good in any way whatsoever)?

Note that the paper says it compared Xok/ExOS to OpenBSD 2.2 (from 1997), and Microsoft's IIS version 2 (1996), and 200 MHz Pentium Pro CPUs (from 1995). The paper might be more recent (the copyright says 2002) but even if the paper is more recent I'd be willing to bet that their benchmarks were taken "as is" from old research done in 1997 and were not repeated on software and hardware from this century.

I'll also note that the choice of OpenBSD for comparison seems a little disingenuous. The OpenBSD project is not known for chasing performance - they're known for chasing correctness and security. If I were doing such a comparison, I'd want to include Linux, and maybe Solaris (both are known for fast networking stacks - especially Linux these days).

I'd also want to include a modern, high performance web server - say, nginx (also known for performance).

[Brendan]

Hi,

Individual applications can request specific CPUs, the kernel, "securely multiplexing hardware," hands out CPU time, and also notifies the applications so they can decide what to do with the particular CPU they're running on.

There's no reason a monolithic kernel can't do this (but most don't/won't because it's much less able to adapt quickly/dynamically and has higher overhead).

Actually it has less overhead. Instead of picking a thread and restoring its state to the newly chosen CPU, the kernel just jumps to a fixed entry point in the process, which can then make the thread decision itself and restore exactly the state it needs.

So you mean it's a complete pile of trash with no support for sane pre-emption, has severe "denial of service like" problems at every possible opportunity, and does a virtual address space switch (large amount of overhead) to hopefully maybe if you're lucky avoid a few trivial register loads? Do they also do a task switch to a process to notify the process that it didn't get CPU time?

When you provide those "very low level kernel API abstractions" and still protect applications from each other, you are an exokernel. At that point, you may as well move the high level abstractions out of the kernel to 1) make them more easily modified/debugged, 2) reduce system call overhead, and 3) reduce the surface kernel attackers can target.

No; it makes you a monolithic kernel that implemented some lower level abstractions where it's beneficial in practice (rather than merely beneficial in some researcher's synthetic "apples to oranges" benchmark).

Now you're just arguing over definitions. "Exokernel" is defined as a kernel that avoids abstraction and instead provides low-level interfaces. The motivation doesn't matter- it's still using exokernel principles, and if it's a dominant characteristic of your design, it's an exokernel. I honestly don't care what you call it, as long as you understand what I mean when I say it.

Ah, I see now. A monolithic kernel is a kernel that doesn't have to implement "too low level" abstractions when they're bad in practice (even if they're good in theory/research); while an exo-kernel is a kernel that has no choice and has to be bad in practice.


Cheers,

Brendan

[Combuster]

I'll also note that the choice of OpenBSD for comparison seems a little disingenuous. The OpenBSD project is not known for chasing performance - they're known for chasing correctness and security. If I were doing such a comparison, I'd want to include Linux, and maybe Solaris (both are known for fast networking stacks - especially Linux these days).

I'd also want to include a modern, high performance web server - say, nginx (also known for performance).

But also, it isn't fair to demand a comparison of a 15-year-old alternative kernel design to todays standards of kernels - especially that they have accumulated 15 years of bloaty guessware to make things act faster, if they haven't actually included some concepts from that design itself - a selection the optimisations you would typically expect in the libos have been added as alternative paths in the linux kernel, as well as entirely new close-to-hardware interfaces.

Also, back when they started, Linux was hardly a meaningful candidate, and therefore rightfully omitted. Solaris (and aix, irix and hp-ux and the whole shebang of times past) is still shrouded in its own share of commercial mysteries that makes it hard to tell if they should have been included back in the day. I'd like to hear an excuse from the authors regarding OS/2 and Windows NT though...


As for redoing the research, by now you'd have two possible outcomes: either you only prove that a year's worth coding of a small team would be inferior to 15 years of an entire community's efforts and renewed insights - which is essentially such an unfair comparison that it's worth nothing, or less likely (but all the more hilariously), that the entire monolithic design was wrong all this time. I think no bets would be wagered here since we all expect the same outcome.

So you mean it's a complete pile of trash with no support for sane pre-emption, has severe "denial of service like" problems at every possible opportunity, and does a virtual address space switch (large amount of overhead) to hopefully maybe if you're lucky avoid a few trivial register loads? Do they also do a task switch to a process to notify the process that it didn't get CPU time?

i.e. did not read.

[Brendan]

Hi,

I'll also note that the choice of OpenBSD for comparison seems a little disingenuous. The OpenBSD project is not known for chasing performance - they're known for chasing correctness and security. If I were doing such a comparison, I'd want to include Linux, and maybe Solaris (both are known for fast networking stacks - especially Linux these days).

I'd also want to include a modern, high performance web server - say, nginx (also known for performance).

But also, it isn't fair to demand a comparison of a 15-year-old alternative kernel design to todays standards of kernels - especially that they have accumulated 15 years of bloaty guessware to make things act faster, if they haven't actually included some concepts from that design itself - a selection the optimisations you would typically expect in the libos have been added as alternative paths in the linux kernel, as well as entirely new close-to-hardware interfaces.

Should we find a modern exo-kernel that has the security and features needed for real servers plus all the compatibility and "bit rot" hassles that come with age; and then compare that to a lean/minimal monolithic kernel that was only ever designed for performance (that lacks the overhead caused by acceptable security, features and compatibility)?

More seriously; when trying to decide the advantages/disadvantages of ideas it's silly comparing specific implementations of those ideas because there's a massive variation between different possible implementations of the same idea. It's like someone that wants to believe that creatures living on land are larger, who compares an elephant and a sardine and says it's proof that creatures that live on land are larger. It's all about confirmation bias and not proof at all.

Instead, you have to look at the ideas and not get distracted by any specific implementation. This is where the idea of exo-kernels fails - for all cases were "lower level abstractions" are useful a monolithic kernel can implement those lower level abstractions; and for all the cases were "lower level abstractions" are not useful and just make things worse a monlithic kernel doesn't have to implement those lower level abstractions; and therefore it's impossible for the idea of an exo-kernel to be better than the idea of a monolithic kernel (but still entirely possible for a specific implementation of either to be better than a specific implementation of the other).

So you mean it's a complete pile of trash with no support for sane pre-emption, has severe "denial of service like" problems at every possible opportunity, and does a virtual address space switch (large amount of overhead) to hopefully maybe if you're lucky avoid a few trivial register loads? Do they also do a task switch to a process to notify the process that it didn't get CPU time?

i.e. did not read.

I.e. getting bored with people that repeatedly fail to make any logical/sane argument for exo-kernels (beyond flawed "apples vs. oranges" benchmarks from biased and worthless research papers; and/or recycling things that monolithic kernels have been doing for a very long time, including things like "M:N" threading models that are older than the exo-kernel idea itself).


Cheers,

Brendan

[Combuster]

confirmation bias and not proof at all.
(...)
I.e. getting bored with people that repeatedly fail to make any logical/sane argument for exo-kernels

And yet you're still doing exactly that, but then the other way around - because you happen to have the opposite opinion.

I've already said all the things I considered needed to be said regarding exokernels. Now all that's left is dealing with your ad nauseam arguments - because all you're doing is being frustrated and repeating all your earlier arguments and fallacies in a different form.

[Rusky]

You're still playing word games. Why are monolithic kernels allowed to make low-level interfaces and not be considered exokernels, while exokernels are not allowed to provide abstractions and still be called exokernels? Why are ideas that follow exokernel concepts not allowed to be considered exokernel-like just because they were invented before exokernels?

Scheduler activations are well-researched, and were abandoned because it was complex to support in an existing operating system alongside 1:1 threading, not because of poor performance or stability. Comments like "does a virtual address space switch to hopefully maybe if you're lucky avoid a few trivial register loads" and "Do they also do a task switch to a process to notify the process that it didn't get CPU time?" show that you do not understand what they are.

[zeitue]

I'd like to add a few thoughts and questions to this post.

Questions:
Do Exokernels run all the user space stuff in just a single address space?
If you Exokernels run programs in individual address spaces then do the libOSes use only a single address space per libOS?

Thoughts:
You might take a look at the AmigaOS family, which are pretty much Exokernels, this includes AROS, AmigaOS, and MorphOS.
AROS, for example is implemented as a bunch of libraries which form the OS in user space and even exec which is which is their kernel is a library in user space. AROS programs will link themselves to exec.library at start, exec is mapped into each programs address space and this gives the program access to resources such as other libraries, memory, objects, ....

Virtual machines, Hosted kernels, and Exokernels:

Virtual machines are quite a broad category they can range from emulators to virtual hardware platforms like Virtualbox to software platforms like Java's JVM, however, virtual machines supply a similar convention to that of the Exokernel. Both virtual machines and Exokernels allow the user to run multiple OSes/LibOSes as well as providing hardware multiplexing. The big difference between these two is the level of abstractions between the apps/OS/LibOS and the hardware as well as the fact that on an Exokernel you're dealing with real hardware rather than virtual hardware.

AROS is not just an Exokernel but also a hosted kernel, that's right AROS can run on either bare hardware or on top of a host like Linux or BSD or even Android. One advantage I can see in the Exokernel design is that you can code hosted or on bare hardware, so you can develop it faster using user space tools such as debuggers and tracers, as well as not having to reboot in between testing components. In addition libraries can be written hosted and used on both the chosen host and the Exokernel itself.

[Brendan]

Hi,

I've already said all the things I considered needed to be said regarding exokernels. Now all that's left is dealing with your ad nauseam arguments - because all you're doing is being frustrated and repeating all your earlier arguments and fallacies in a different form.

That's because these arguments aren't fallacies, are the only arguments that make any logical sense, and you're ignoring them because you're unable to refute them.

You're still playing word games. Why are monolithic kernels allowed to make low-level interfaces and not be considered exokernels, while exokernels are not allowed to provide abstractions and still be called exokernels? Why are ideas that follow exokernel concepts not allowed to be considered exokernel-like just because they were invented before exokernels?

If you're trying to pretend a kernel with a mixture of high level abstractions and low level abstractions is not a monolithic kernel, then you've redefined "exo-kernel" to include every monolithic kernel and it becomes meaningless.

The exo-kernel concept is "only what's needed for secure resources sharing in kernel". Low level abstractions are just a means to an end; and if you add something like "M:N threading model" to an monolithic kernel you're only using low level abstractions for some things (and not others) and aren't using the "only what's needed for secure resources sharing in kernel" concept.

Scheduler activations are well-researched, and were abandoned because it was complex to support in an existing operating system alongside 1:1 threading, not because of poor performance or stability. Comments like "does a virtual address space switch to hopefully maybe if you're lucky avoid a few trivial register loads" and "Do they also do a task switch to a process to notify the process that it didn't get CPU time?" show that you do not understand what they are.

For a lot of monolithic kernels; after implementing "M:N threading" and comparing it to "1:1 threading" in side-by-side "apples vs apples" comparisons; a lot of monolithic kernels chose to throw away "M:N threading" instead of throwing away "1:1 threading" (and instead of keeping both). Some OSs (e.g. Windows) did keep both. I can only assume each of these OSs made the decision that was right for them.

None of these kernels needed to be exo-kernels to do this; and none of them suddenly became exo-kernels because of this.


Cheers,

Brendan

[Brendan]

Hi,

Questions:
Do Exokernels run all the user space stuff in just a single address space?
If you Exokernels run programs in individual address spaces then do the libOSes use only a single address space per libOS?

Each process has its own library mapped into that process' virtual address space (where the library may be different for different processes, but is often just the same library mapped into each separate process' address space).

Thoughts:
You might take a look at the AmigaOS family, which are pretty much Exokernels, this includes AROS, AmigaOS, and MorphOS.
AROS, for example is implemented as a bunch of libraries which form the OS in user space and even exec which is which is their kernel is a library in user space. AROS programs will link themselves to exec.library at start, exec is mapped into each programs address space and this gives the program access to resources such as other libraries, memory, objects, ....

Most people say AmigaOS's kernel is a micro-kernel. However, there's no MMU and no isolation between "user space" and "kernel space" so it could just as easily be classified as a modular monolithic kernel or a micro-kernel. For example, device drivers are "libraries", and you could say they're modules for a monolithic kernel or you could say they're processes for a micro-kernel. They aren't "per process libraries" though, so you can't say they are libOSs for an exo-kernel.

AROS is not just an Exokernel but also a hosted kernel, that's right AROS can run on either bare hardware or on top of a host like Linux or BSD or even Android. One advantage I can see in the Exokernel design is that you can code hosted or on bare hardware, so you can develop it faster using user space tools such as debuggers and tracers, as well as not having to reboot in between testing components. In addition libraries can be written hosted and used on both the chosen host and the Exokernel itself.

Like AmigaOS; I doubt anybody considers AROS to be an exo-kernel. Most people consider it to be a micro-kernel but some think it's a hybrid monolithic kernel, and (due to the lack of isolation between user space and kernel space) it's hard for anyone to really say one way or the other.


Cheers,

Brendan