mds [pronounced /m.d.s/] (or µds [pronounced /micro.d.s/])
stand for “micro-display server”. It is a toy project of a
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 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. 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 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.
Read the discussion at the end of the info documentation,
it contains meditation on how to make even better display
servers.
Is this vapourware? Probably, I often get bored with
graphical projects. Graphics sucks.
