% % !TEX root = MasterThesis.tex

\chapter{Conclusion}\label{ch:conclusion}
The present work and its evaluation can be divided into a theoretical and a practical part.
While the former deals with general operating system concepts and their use in Zircon as a recently implemented microkernel approach in comparison to the older monolithic Linux kernel, the second part focuses more on their differences in driver development.
The architectures and objectives of microkernel and monolith systems are fundamentally different, whereas the concepts used for basic operating system tasks are often similar.
Overall, however, these are optimized for the use in their respective architecture.
Especially Zircon presents an implementation idea that demonstrates a great deal of knowledge and experience in the field of operating system development and clearly shows that the developers have learned from aspects that are not necessarily optimally solved in Linux, e.g.\ for historical and/or compatibility reasons.
Examples for these are, amongst other things, the handling of system calls or the memory management.
Due to the lack of \ac{posix} compatibility, Zircon enables an unencumbered design of systemcalls and adapts them to modern needs, but the enforcement of \acp{vdso} and the use of \texttt{libzircon.so} for all systemcall implementations is interesting from a security aspect, as well.
Linux is very architecture dependent regarding memory management.
The multitude of architectures and their associated terms and concepts makes them difficult to understand and use correctly, even for experienced developers.
In this context Zircon is, as far as it can be read from the documentation, much more stringent and as well, simpler.
Without a division into memory areas with explicit meaning for different tasks, both, understanding and development becomes easier.
On the other hand, there are also concepts used in Zircon, which, based on the experiences with Linux, can be assumed to fail for maintainability reasons with a possible spread of Zircon.
An example is the way Zircon deals with board definition files which is discussed in section~\ref{sec:cs-zircon}.

The circumstances are similar for the actual driver development as well.
Conceptually, the influences of the microkernel become slightly visible in the lifecycle of a driver, for example when binding the driver to a device and for the selection of the superior device host process.
Within the driver development itself, the differences to Linux are rather caused by the collective experiences and the selection of more modern approaches.
Neither the break with the \ac{posix} standard nor the introduction of \ac{fidl} or the support of a wider range of programming languages in kernel and drivers are direct consequences of an operating system kernel architecture, but a reaction to learnings from Linux and other operating systems.
Nevertheless, exactly these aspects make the development on Zircon truly pleasant.

Because of the well-written documentation, the transition to C drivers in Zircon is very smooth, only the documentation for the definition of devices and for board files as a whole are missing.
The change to C++ drivers is more difficult, because there is hardly any documentation.
By taking advantage from advanced C++ concepts, such as mixins these drivers become much more difficult to understand while the corresponding situation is obvious in a C implementation.
Furthermore, C and C++ \acp{api} are often mixed within already existing C++ drivers in the used version level.
On the one hand this is motivated with missing C++ bindings for certain tasks in the used version level, as it is e.g.\ the situation for \ac{fidl}, on the other hand simple inconsistencies are probably an issue.
But if the connections between C and C++ drivers are clear, C++ becomes very interesting and sufficient for driver development.
In this context, it is also interesting to see how the development and language prioritization in Zircon will change when the support for \textit{Rust} is ready for use.
Considering the current Zircon development, the general trend is to replace C drivers with C++ ones.
Rust could be even more interesting from a security point of view.
As a programming language it is not as mature and wide-spread as C and C++.
Overall, the development workflow for Zircon appears well thought-out and coherent, no matter which programming language or compiler is used.
However, most of the accompanying tools in Zircon are based on LLVM and therefore, require a Clang build.
Linux slowly allows the use of Clang and LLVM as well, justified with the advantages of the same tools as known from Zircon.
But none of these toolchains had a noticeable influence on the development which is why a more detailed compiler analysis was skipped.

The microkernel was able to play off its strengths mainly in its actual use.
While a bug in Linux might paralyze the whole system, Zircon, as a microkernel, can react much better.
Unfortunately, the exact behavior in such situations is not yet documented.
But during the development, two situations have caught the attention.
First, it is the behavior of the driver respectively of the device coordinator in case of failed initializations during binding, second, it is the handling of incorrectly typed \ac{fidl} calls.
In the first situation, a device can not be initialized and the \mintinline{c}{bind()} method of the corresponding driver ends with certain status codes which signal the device coordinator to try a number of initializations in the hope that a temporary issue can be solved.
In the other one, the strong typing of \ac{fidl} calls becomes obvious.
While a faulty buffer in an \mintinline{c}{ioctl()} call can potentially cause a lot of damage in Linux, \ac{fidl} call arguments are already checked at the beginning.
If these do not match the defined call, the whole connection between user and the \ac{fidl} interface of a driver will be reset.
Indeed, it is necessary to reconnect to the driver again, but wrong parameters can only cause little to limited damage by this check and the concept of distinct device hosts at all.
In the attempts regarding the use of \ac{fidl} calls within the case study typically it was only possible to identify crashes and errors on the basis of informative log messages from the console.
No further effects were observed and the driver could be used as usual.

The observed situations both belong to the desired effects of the microkernel or rather \ac{fidl}, even if they are unfortunately not documented at all.
However, these positive effects also result in the significant performance losses discussed as part of the previous chapter.
Whether one would accept depends very much on the application of a kernel respectively a system.
For Zircon, however, these losses are clearly accepted in favor of the advantages.
Even though Zircon's impression in this thesis is very positive, this does not automatically imply that Linux is worse.
The fundamentally different architectural concept is clearly visible but very much influenced by Linux's origins.
It can also be easily seen that the developers of Zircon have considered problems and unpleasant issues in Linux and consciously implemented them in a different manner.
Examples are, of course, \ac{fidl}, the context pointers and the whole break with the \ac{posix} standard, as well.
This development can also be traced back to the history of both systems and especially Linux.
In addition, Zircon is currently not used for production.
Thus, there is much more space for experiments.
Of course, it would be very desirable that some of these experiments and concepts find their way into Linux over time.
Especially in driver development, these could be context pointers and \ac{fidl} call definitions instead of \ac{io} controls.
For both of them a realization in Linux is technically conceivable, independent of the underlying operating system kernel architecture, but how likely a realization is, remains open.
Accordingly, a kernel architecture has less influence on driver development than the use of modern concepts that address issues of other kernels such as Linux.
However, the architecture and resulting effects of a kernel have a significant effect on its intended use.




% - konzepte
    % - how implemented
% - treiber implementierungen
    % - konzeptuelle unterschiede
    % - auswirkungen auf die programmierung
    % - workflow und tools
% - auswirkungen des mikrokernels im betrieb
    % - umgang mit fehlern und ausfällen
    % - benutzung vom user aus
% - performance
% - bewertung im hinblick auf historische entwicklung
% - frage ob es sich lohnt für die vorzüge aber auch die geschwindigkeitseinbußen auf zircon zu wechseln
% -> wie wird sich die performance entwickeln, wie wird sich zircon selbst entwickeln, wird es überhaupt tatsächlich eingesetzt und wenn ja wo?...

