So let's put it all together the mechanisms exokernel offers, and how
library operating systems can live on top of this red line, that is the
protection boundary for exokernel. And, meaningfuly
execute applications that belong to it on
the hardware resources, and not interfere
with one another. That is, achieve both
extensibility, protection, and performance. So one of
the hooks for getting good performance is what
I mentioned earlier, and that is called
that a performance critical for library operating system
is something that can downloaded securely into
the exokernel, so that piece of code becomes
sort of the extension of exokernel. For a
particular library operating system. This may be for
OS one, this maybe for OS two and so on and so forth. So, now with this setup
at any point of time some application process of some library operating system
is running on the CPU. Now remember that
Exokernel has no idea about processes within any
of these library operating systems. All it knows
is existence of these library operating systems and
the fact that Exokernel has been the broker in giving some hardware
resources. Capabilities for some hardware resources,
I should say, to specific library operating
systems, and it has also been the broker for downloading some code specific to
library operating systems. Into the exokernel code base itself. Let's say that
this particular thread belongs to this library
operating system as long as this thread is
well behaved by which I mean it's
not doing anything funky. Doing normal program execution.
Accessing memory. For which, mapping exists in
TLB and so on. Life is good. Address
translation happens on every memory access entirely
in the CPU, and the process is making
forward progress at memory speeds without intervention
from exokernel or any of the library
operating system. But, there could be this
discontinuities, in the execution of this process. For
example, let's say that this processor thread
makes a system call, like opening a file.
When it does that, that is a
discontinuity in the normal execution of this process.
Or worse yet, it may incur a page fault, meaning that not all of the pages
for this particular process is currently In the
mapping available to the hardware in the TLB, and
therefore, there's a page fault. Even worse, this
thread could do something stupid, such as divide by
0, or something like that, that causes an
exception. And lastly, the thread is not doing anything
to cause the discontinuity, but there is an external interrupt that came in And
that is going to cause a discontinuity to this execution of this
process on the CPU. All such discontinuities essentially
result in the CPU incurring a fault or a trap, and
the trap is fielded by exokernel. When such discontinuities occur,
exokernel has to pass the program discontinuity
to the appropriate library operating system that is
living on top of it. Now, exokernel knows, based on the linear vector of time
slots that I mentioned earlier Which library
operating system is currently running on the CPU.
And therefore, it knows the right library
operating system to which it has to pass
the discontinuity that occurred right now for the currently executing process.
To facilitate a finer-grain association between these different kinds of
discontinuities. And the specific functionality
in the library operating system for
dealing with those discontinuities exokernel
maintain state for each currently existing
library operating system and we will discuss the state maintained
by exokernel. On behalf of every library operating system next.