improve readme and include must of the readme to the overview chapter

Signed-off-by: Mattias Andrée <maandree@operamail.com>

1 files changed, 46 insertions, 0 deletions

diff --git a/doc/info/mds.texinfo b/doc/info/mds.texinfo
index d198cbf..d0befae 100644
--- a/doc/info/mds.texinfo
+++ b/doc/info/mds.texinfo
@@ -74,6 +74,52 @@ a perfect graphical experience. @command{mds} is all
 about flexibility and freedom 0@footnote{The freedom to run
 the program as you wish, for any purpose}.
 
+The reason for having a display server architectured as a
+microkernel is so that components can be added, remove
+and replaced online. Additionally, the message passing
+between the servers makes it easy to design a system that
+lets you make clients that can listen on messages between
+the servers and perhaps modify them. This enables you to
+do so much more with your display server. Moreover, if
+a single part of the system crashes it does not bring down
+the whole system, and the crashed server can be respawned
+with minor side effects. @command{mds} is architectured
+in three layers: a microkernel, a master server and a
+collection of servers. And clients are actually located
+on the same layer as the servers, because there is no
+actual difference, the only thing that separates a server
+from a client is for what purpose you run it. @command{mds}'s
+kernel is a minimal program that do initialisation of the
+display, such as giving it an index and create runtime
+files and directories for servers and other programs
+to use. Then the kernel creates a domain socket for the
+master server and spawns the master server and respawns
+it if it crashes. Because of this, if the master server
+crashes it will not lose its socket when it is respawned.
+The master server than, on its initial spawn, starts
+the all servers and other programs that the user have
+choosen and then starts accepting connections to it and
+coordinates messages between servers and clients. Further,
+separating all components into separate processes enables
+us to only give the servers the privileges they actually
+need, rather than having one program with root privileges
+that takes care of everything even things that do not do
+require any privileges.
+
+All @command{mds}'s servers, that is all running parts of
+@command{mds} except the kernel, are designed so that they
+can re-exec themself so that they can be updated online
+without any side effects. Servers serialises their state,
+saves it to RAM (in a directory created by the kernel),
+re-exec themself and loads their serialised state. The
+kernel cannot do this because when it has spawned the
+master server it has no reason to re-exec, its only mission
+is to respawn the master server it if would happen to crash.
+It would technically be possible to enable the kernel to
+re-exec but it is not worth it as it as no reason to
+re-exec, and doing so puts the display server at risk
+of crashing.
+
 
 
 @node Architecture