diff options
Diffstat (limited to 'doc/info/mds.texinfo')
| -rw-r--r-- | doc/info/mds.texinfo | 46 |
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 |