Information Technology Reference
In-Depth Information
corrected libraries to the users of an extensible
operating system should be straight forward. So,
if extensibility means there might be fewer bugs
or issues in the kernel, and also if extensibility
means updated user level libraries might be eas-
ily added to an existing system, then perhaps an
extensible operating system might lead to less of
a customer support issue.
Furthermore, one might even argue that cus-
tomer support will be easier to provide with an
extensible operating system. Consider a customer
support issue that arises from the use of a par-
ticular user level library. In so far as the issue is
contained within that one user level library, then
the customer support provider only needs to be
an expert in that one library. This means customer
support employees can be specialized. In so far
as it is easier to train someone to be an expert
in a limited number of user level libraries rather
than an expert in the entire operating system, it
seems that training customer support personnel
will also be much easier with an extensible op-
erating system.
wants maximum flexibility then one must move
all management out of the kernel and make the
code available in user-space.
The point we are trying to argue is that maybe
eliminating all management from the kernel is
too strong of a position. Maybe some manage-
ment should remain in the kernel while other
management code should be moved to user-space
where it can be modified and optimized. Further
research into this issue may reveal that maximum
optimization can be achieved even if the operating
system kernel retains some of the management
responsibility.
As an illustration of our point, we cite Riech-
mann and Kleinöder as they state “As multithread-
ed applications become common, scheduling
inside applications play a very important role for
efficiency and fairness” (Riechmann, & Kleinöder,
1996). They further state the Exokernel's design
leads to inefficiency because the Exokernel's
thread scheduling algorithm requires an additional
thread switch during execution. Their solution is to
separate the management policy from the manage-
ment implementation. Their research demonstrates
that if one places the thread switching mechanism
inside the kernel while allowing user-level code
to handle the scheduling algorithm, some effi-
ciency is gained over the Exokernel's approach.
The idea of two level scheduling was also used
by (Reuven & Wiseman, 2006) even though they
suggest to implement both of the scheduling level
within the kernel, but their implementation will
be activated only if thrashing occurs (Wiseman,
2009), (Jiang, 2009).
Riechmann and Kleinöder argue our point
for us. Our point is that perhaps a clean division
between implementing protection within the ker-
nel and implementing management within user
code is too extreme. The research conducted by
Riechmann and Kleinöder suggests that a pure
Exokernel approach might not be the best answer.
The Exokernel's approach needs to be embraced,
but just not tightly. In conclusion, perhaps the best
design for an operating system is one in which
eliminating management
One may argue that it is not necessary to eliminate
all management from the operating system. Per-
haps there are some operating system management
functions that cannot be further optimized, and
therefore, they should continue to be provided by
the kernel. Or, perhaps the amount of optimization
that is possible is so small as to not be worth the
effort to move them outside the kernel. Perhaps the
better approach is to allow the kernel to manage
those processes that cannot be further optimized
and to move into user-space that code that can
be further optimized. A very logical question is -
how will we know when code cannot be further
optimized? Unfortunately, this is a question that
cannot be answered without some further experi-
ence. On one hand, it seems that all processes will
probably agree upon some common approaches
to management, whereas on the other hand, if one
Search WWH ::




Custom Search