From 146ae7e11cda9a3c2b94c88dfd1f1c56d0ab7fe7 Mon Sep 17 00:00:00 2001 From: Mattias Andrée Date: Sun, 27 Apr 2014 16:54:30 +0200 Subject: fix readme MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Mattias Andrée --- README | 53 +++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 43 insertions(+), 10 deletions(-) diff --git a/README b/README index 56c65c8..c25b235 100644 --- a/README +++ b/README @@ -4,16 +4,49 @@ display server with an architecture resembling that of a microkernel. The reason for having a display server architectured as a -microkernel is so that components of the display server -can be replaced online. That is, when you install a newer -version of the display server you can start running the -new version without having to restart the display server. -Moreover, it allows you to replace components with your -own versions or add new components, with exception of -parts that need the special privileges and one special -component, the program that starts it all, but that file -will have no mission except restarting the master server -if it crashes once it has started the master server. +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 lets +lets you make clients that can listen on messages between +the servers and perhaps modify them. This enables you to +do some much more with your display server. Moreover, +if a single part of the system crashses it does not bring +down everything, and the crahsed server can be respawned +with minor side effects. 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. 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 mds's servers, that is all running parts of mds +except the kernel, are designed so that they can re-exec +themself so that they can be replace 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 has spawn the master server +it has no reasone to re-exec, its only mission is to +respawn the master server it if would happen to crash. +It would (probably) technically be possible to enable +the kernel to re-exec but it is not worth it as it as +no reason to rexec, and doing so raises some challenges. Is this vaporware? Probably I often bored with graphical projects. Graphics sucks. -- cgit v1.2.3-70-g09d2