Editing Microkernel (section)

==Servers==
Microkernel servers are essentially [[daemon (computing)|daemon]] programs like any others, except that the kernel grants some of them privileges to interact with parts of physical memory that are otherwise off limits to most programs. This allows some servers, particularly device drivers, to interact directly with hardware.

A basic set of servers for a general-purpose microkernel includes file system servers, device driver servers, networking servers, [[display server]]s, and user interface device servers. This set of servers (drawn from [[QNX]]) provides roughly the set of services offered by a Unix [[monolithic kernel]]. The necessary servers are started at system startup and provide services, such as file, network, and device access, to ordinary application programs. With such servers running in the environment of a user application, server development is similar to ordinary application development, rather than the build-and-boot process needed for kernel development.

Additionally, many "crashes" can be corrected by simply [[Crash-only software|stopping and restarting the server]], which would not be feasible if the entire kernel had to reboot. However, part of the system state is lost with the failing server, hence this approach requires applications to cope with failure. A good example is a server responsible for [[Internet protocol suite|TCP/IP]] connections: If this server is restarted, applications will experience a "lost" connection, a normal occurrence in a networked system. For other services, failure is less expected and may require changes to application code. For QNX, restart capability is offered as the QNX High Availability Toolkit.<ref>{{cite web|url=http://www.qnx.com/download/download/8107/QNX_High_Availability_Toolkit.pdf|title=The QNX High Availability Toolkit|archive-url=https://web.archive.org/web/20050824015422/http://www.qnx.com/download/download/8107/QNX_High_Availability_Toolkit.pdf|archive-date=24 August 2005 }}</ref>