diff --git a/doc/release_notes-15-11.txt b/doc/release_notes-15-11.txt
new file mode 100644
index 000000000..ce4bcb464
--- /dev/null
+++ b/doc/release_notes-15-11.txt
@@ -0,0 +1,1429 @@
+
+
+ ===============================================
+ Release notes for the Genode OS Framework 15.11
+ ===============================================
+
+ Genode Labs
+
+
+
+In the
+[http://genode.org/documentation/release-notes/15.08 - previous release],
+we proudly reported the initial use of Genode as day-to-day OS. With the
+current release, we maintained the strong focus on making Genode viable as the
+foundation of a desktop OS. There are many aspects to be considered, ranging
+from configuration concepts, over the GUI and audio architectures, to
+device-driver support. Section [Genode as desktop OS] gives insights into this
+development and our train of thoughts.
+
+Speaking of device drivers, the current release comes with the Intel KMS
+driver ported from the Linux kernel and running as a user-level component. The
+driver allows us to drive multiple displays and change screen resolutions on
+the fly. Since the driver code relies on the Intel GEM infrastructure of the
+Linux kernel, we had to port those subsystems as well. So the new driver could
+be taken as starting point for a user-level GPU multiplexer in the future.
+
+In addition to those prominent features, the release comes with numerous
+improvements and additions. For example, we enhanced the support for the USB
+Armory (a dedicated article about this work will follow soon), added support
+for Xilinx Zynq-7000, and optimized our version of VirtualBox for NOVA.
+
+According to our
+[http://genode.org/about/road-map - road map], we planned to address package
+management, a modern web browser, and cross-kernel binary compatibility with
+the version 15.11. However, we decided to put emphasis on the general
+usability, robustness, and scalability first, before entering new
+developments. So those topics are not covered by the current release. That
+said, package management is a topic of ongoing active development within our
+community. Most of the file-system improvements featured in the current
+version were motivated by this line of work.
+
+Where do we stand with the use of Genode as desktop OS? Currently, there is a
+hand full of people using Genode as day-to-day OS. By eating our own dog food,
+we are able to recognize and remedy all the little issues that stand in our
+way. Hence, the user experience is steadily evolving. Still, at the current
+stage, it is not palatable for end users with no background in the development
+with Genode. For installing a Genode-based desktop OS, one has to compile and
+configure all components from source, there is no package management, there
+are no wizards that guide you, and there are no GUI dialogs for configuring
+the system. However, all the pieces for creating a system that is practically
+usable are [https://github.com/genodelabs/genode/issues/1552 - available], and
+putting them together is a lot of fun!
+
+
+Genode as desktop OS
+####################
+
+The overall theme of the current release is the use of Genode as a desktop
+operating system. The state of development is best expressed by the screenshot
+of the Genode/NOVA-based setup used by Norman on his x201 Thinkpad.
+
+[image turmvilla_screenshot_small]
+
+Under the hood, the new Intel KMS driver
+(Section [Intel-KMS framebuffer driver]) drives the external '1920x1200'
+display in addition to the internal LCD display of the laptop. The wireless
+network has just been configured via the noux session located at the bottom left
+facilitating the configuration concept explained in Section
+[Uniform run-time configuration concept]. The windows are decorated with a new
+window decorator that supports drop shadows and translucent decorations. The
+decorator can be tweaked and even replaced at runtime.
+
+
+Uniform run-time configuration concept
+======================================
+
+For using Genode as a desktop OS, we had to find answers to a number of
+questions regarding the configuration of both long-living low-level components
+as well as high-level applications:
+
+* How to pass parameters to applications when they are started?
+
+ Whereas the common approach of argc-argv-based command-line arguments is
+ nice for the interactive use at a shell, it does not scale well: Structured
+ information is hard to express and the syntax varies from application to
+ application.
+
+* Where are configurations stored and how do applications obtain them?
+
+ Traditionally, programs obtain their configuration data from well-known
+ locations at the file system like the _/etc/_ directory or dot files in the
+ home directory. On Genode, however, there is no common file system structure
+ and the notion of a home directory does not even exist.
+
+ Alternatively, configuration data could be stored at a central "registry"
+ service. But such a database-like mechanism is less transparent to the user
+ and creates a bunch of new problems with respect to management and access
+ control. Furthermore, the impact of such a nontrivial central component on
+ the system's trusted computing base cannot be neglected.
+
+* Is it possible to cover the configuration needs of low-level components like
+ device drivers and file systems with the same mechanism as used by
+ high-level applications?
+
+* How can the configuration of a long-living component be tweaked at runtime
+ without the need to restart it?
+
+We attempted to answer these questions with a single mechanism in version
+[http://genode.org/documentation/release-notes/12.05#System_reconfiguration_at_runtime - 12.05].
+But the scalability of the approach remained unproven until now.
+
+In short, configuration information is supplied to a component by its
+immediate parent component in the form of a ROM session with the name
+"config". A ROM session represents a piece of data (ROM module) that can be
+made visible in the component's address space. Furthermore, the ROM session
+allows the component to register a signal handler that is notified should a
+new version of the ROM module become available. The component can - at its
+discretion - respond to such a signal by requesting the new version.
+Consequently, a ROM session is a way to transfer information from the ROM
+server to the ROM client in a transactional manner. When used as configuration
+mechanism, the server is the parent and the client is the child component.
+From the child's perspective, it is irrelevant where the information comes
+from. The parent could have read it from a file system, or obtained it from
+another ROM service, or could have generated it. By convention, configuration
+data has an XML-like syntax, which allows us to express arbitrarily structured
+information.
+
+[image backdrop_edit_config]
+
+The figure above illustrates an example scenario. The backdrop component
+obtains a description of the background composition as its "config" ROM
+module. The init component routes this ROM-session request to the FS-ROM
+server, which provides a ROM service by reading the content of ROM modules
+from a file system. The same file system can, of course, also be accessed by
+other clients. At the right side, a noux instance executes an editor like Vim
+to edit files in the file system. Each time, the file is saved by the editor,
+FS-ROM gets notified, which, in turn, notifies the backdrop to update its
+configuration. This way, a desktop background can be interactively changed
+using Vim.
+
+With the current release, we have incorporated the ability to dynamically
+respond to configuration changes into many components to make them ready for
+the use in a desktop environment. To illustrate the flexibility of the
+mechanism, we can perform the following operations by merely editing text files
+as explained in the backdrop example above.
+
+* Letting our new Intel KMS driver (Section [Intel-KMS framebuffer driver])
+ change screen resolutions or enable/disable connectors.
+
+* Changing the volume of audio channels per application or the master volume.
+
+* Changing the colors, style, and the placement of window controls of the
+ window system.
+
+* Changing the policy of the nitpicker GUI server such as the tinting of
+ screen regions depending on the labels of the visible applications.
+
+* Connecting to a wireless network by editing the configuration of the Intel
+ wireless driver.
+
+* Replacing an entire subsystem by a new one by replacing the configuration of
+ a nested instance of the init component.
+
+* Assigning a USB device to a subsystem by editing the USB driver's
+ configuration.
+
+All these use cases are covered by the same mechanism. Because configurations
+have a textual form with a uniform syntax (XML), the approach implicitly gives
+us the following benefits:
+
+* Configurations can be annotated with comments, managed via a revision-control
+ system like Git, and compared to older versions via diff tools.
+
+* Because the mechanism is based on a textual representation, accessibility
+ of all configuration-related operations is built-in into Genode by default.
+
+* The response of components to configuration changes can be subjected to
+ automated tests, which merely need to present varying ROM modules to
+ components (as done by the _dynamic_rom_ server).
+
+Combined with the report-session facility that allows components to report
+state to its parent, the configuration concept makes the creation of graphical
+front ends a straight forward experience. For example, a hypothetical
+display-settings dialog would obtain the framebuffer driver's report about the
+available connectors and supported resolutions, present a dialog of options,
+and, in turn, generate new configurations for the framebuffer driver. If a new
+display gets connected, the driver would update its report, triggering the
+dialog to present the new options. Section [Audio stack] presents a similar
+scenario for mixing audio.
+
+
+GUI stack
+=========
+
+Since the first release in 2008, Genode is equipped with a GUI server called
+nitpicker, which plays the role of a secure "hypervisor for graphics". With
+less than 2000 lines of code, it multiplexes the framebuffer and routes input
+events in a secure way. Its low complexity stems from the fact that it does
+contain almost no policy. In particular, it has no notion of "windows" or
+similar common GUI elements. These parts of the GUI must be implemented at the
+client side.
+
+In
+[http://genode.org/documentation/release-notes/14.08#New_GUI_architecture - version 14.08],
+we laid the foundation for a scalable GUI architecture that further reduced
+the functional scope of nitpicker and complements nitpicker with higher-level
+components for managing windows. Thanks to this architecture, most of
+nitpicker's formerly built-in policies such as the pointer shape could be
+moved to separate components that are easy to replace and customize. We were
+ultimately able to incorporate the notion of windows into the architecture
+without introducing a new interface. Instead, the window manager implements
+the same interface as the nitpicker GUI server. Applications are unaware
+whether they talk to nitpicker or the window manager.
+
+[image nitpicker_wm]
+ Both nitpicker and the window manager provide the same (nitpicker
+ session) interface.
+
+With the current release, we push this architecture even further. By
+eliminating the notion of the X-ray mode from nitpicker as explained in
+Section [Rigid separation of policy and mechanism], we further reduce
+nitpicker's responsibilities and greatly improve its flexibility. We managed
+to completely decouple the components for painting window decorations and
+managing window layouts from the window manager to the point where we can
+dynamically replace those components at runtime. Furthermore, we introduce a
+new window decorator
+(Section [Enhanced window-decorator and window-layouter flexibility])
+that can be styled in a very easy way.
+
+
+Rigid separation of policy and mechanism
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Nitpicker's X-ray mode is a distinctive feature of the GUI server. It allows
+the user to reveal the identity of applications by pushing a special button at
+any time. The following picture shows the effect. In contrast to the original
+version of nitpicker, the new GUI stack allows the window decorator to
+properly respond to X-ray mode changes. Whereas nitpicker is responsible for
+tinting the window content and painting the client's labels as a watermark,
+the window decorator applies the color change to the window decorations.
+
+[image decorator_xray]
+ Normal (left) and X-ray mode (right). While X-ray mode is enabled, the user
+ is able to validate the authenticity of the presented applications
+ and thereby uncover Trojan Horses.
+
+Nitpicker actually does no longer have an X-ray mode. Instead, the individual
+features of the former X-ray mode can be configured for specific client
+labels. Those features are input-focus policy, the tinting with a session
+color, the labeling, and the hovering policy. Behind the scenes, nitpicker is
+reconfigured each time the X-ray mode is enabled or disabled. The following
+diagram shows the scenario:
+
+[image nitpicker_xray_trigger]
+ Interplay of the nitpicker GUI server with externalized policy
+ components.
+
+The X-ray trigger component is a nitpicker client that receives certain global
+key sequences according to nitpicker's configuration. It is thereby able to
+exclusively respond to the X-ray key. Furthermore, it is able to incorporate
+any number of other conditions to decide whether to enable or disable the
+X-ray mode. For example, by making nitpicker's hover reports available to the
+X-ray trigger, X-ray could be automatically enabled while the pointer hovers
+over a panel or the window decorations. The X-ray trigger, in turn, reports
+its decision via an "xray" report. This report is routed as input to the ROM
+filter. The ROM filter responds by generating a new configuration for
+nitpicker.
+
+In addition to the flexibility of making X-ray trigger policy and the actual
+X-ray effect easily customizable, the new approach allows other components
+outside of nitpicker to respond to the X-ray mode, most particularly the
+window decorator.
+
+
+Loose coupling of policy components
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Genode's window manager is not a single program but a composition of several
+components with different responsibilities:
+
+[image window_manager]
+ The window manager merely acts as a low-complexity mediator of potentially
+ complex and policy-rich components like the window decorator and the window
+ layouter.
+
+Both the decorator and the layouter are mere clients of the window manager.
+Window-related information is exchanged between these components via the
+report-ROM component, which provides a publisher-subscriber mechanism by
+implementing Genode's report and ROM session interfaces. Because state
+information is always kept at the report-ROM server outside the decorator and
+the layouter, it is possible to replace those components at runtime without
+losing any information about the state of the present windows. The following
+screenshot shows how the classical window decorator gets replaced by the new
+themed window decorator introduced in the next section.
+
+[image switching_decorators]
+
+
+Enhanced window-decorator and window-layouter flexibility
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*Handling of window controls*
+
+We added support for the common window controls _close_ and _maximize_ to the
+window layouter and decorator. The order of those controls in the window title
+can be configured, and can even be changed at runtime.
+
+When activating the window closer, the window manager sends a resize request
+for the size 0x0 to the corresponding client. It is up to the client to
+implement a meaningful response such as exiting the application.
+
+
+*Tinting of window controls*
+
+Thanks to the separation of the X-ray policy from nitpicker as explained in
+Section [Rigid separation of policy and mechanism], components other than
+nitpicker have become able to respond to the X-ray mode. This is particularly
+useful for the window decorator, which can now take the X-ray mode into
+account for tinting window decorations according to the session colors. We
+enhanced the existing window decorator by a configurable assignment of colors
+for different windows depending on the window labels. Similar to nitpicker,
+the decorator is able to respond to configuration updates at runtime. Even
+though the decorator has no notion of an X-ray mode, it can respond to the
+X-ray mode when combined with a ROM filter, analogously to the configuration
+depicted for nitpicker in Figure [nitpicker_xray_trigger].
+
+
+*New themed decorator*
+
+We created a second decorator to illustrate the versatility of the GUI
+architecture, and to give users a modern-looking alternative to the original
+Motif-inspired decorator. The new themed decorator is located at
+_gems/src/app/themed_decorator/_. In contrast to the original decorator that
+has a built-in style, the new decorator obtains the style information from a
+few PNG images, a font, and a bit of metadata. Those files need to be mounted
+into the VFS of the decorator at the _/theme/_ directory. The following Figure
+[theme] shows the three images _default.png_, _closer.png_, and
+_maximizer.png_ of the default theme.
+
+[image theme]
+
+The corresponding _metadata_ has the following content:
+
+!
+!
+!
+!
+!
+!
+!
+
+The '' node contains the margins for the area around the decorations,
+which gives us room for drop shadows. The '' node contains the margins
+of the actual decorations. The '', '', and '' nodes
+contain the positions of the corresponding window controls with the
+coordinates referring to the coordinates in the _default.png_ image.
+
+
+Audio stack
+===========
+
+While working on the audio stack and improving the support for audio
+applications in VirtualBox, we took the chance to modernize the mixer
+component and applied Genode's dynamic configuration concept to the mixer.
+
+Like all other configurable components, the mixer obtains its configuration
+via a ROM module from its parent. The following configuration snippet
+illustrates its structure:
+
+!
+!
+!
+!
+!
+!
+!
+!
+!
+
+The '' node is used to set up the initial settings for new clients.
+According to this configuration, every new client will start with a volume
+level set to 25 and is not muted. The initial output volume level is set to 75
+(the volume level ranges from 0 to 100). The '' node contains
+all (pre-)configured channels. Each '' node has several mandatory
+attributes:
+
+* 'type' is either 'input' or 'output',
+* 'label' contains the label of a client for an input node and the value
+ 'master' for an output node,
+* 'number' specifies the channel number (0 for left and 1 for right),
+* 'volume' sets the volume level,
+* 'muted' marks the channel as muted.
+
+In addition, there are optional read-only channel attributes, which are mainly
+used by the channel-list report.
+
+The mixer reports all available channels in its 'channel_list' report. The
+report contains a `' node that is similar to the one used in the
+mixer configuration:
+
+!
+!
+!
+!
+!
+!
+!
+!
+
+Each channel node features all mandatory attributes as well as a few optional
+ones. The 'name' attribute contains the name of the channel. It is the
+alphanumeric description of the numeric 'number' attribute. The 'active'
+attribute indicates whether a channel is currently playing or not.
+
+A channel-list report may be used to create a new configuration for the mixer.
+Each time the available channels change, e.g., when a new client appears, a
+new report is generated by the mixer. This report can then be used to
+configure the volume level of the new client. A new report is also generated
+after a new configuration has been applied to the mixer. Thereby, a mixer
+agent becomes able to adapt itself to recent changes.
+
+As an example, there is an experimental mixer agent based on Qt5
+_repos/gems/src/app/mixer_gui_qt_ that processes the mixer generated
+channel-list reports. It takes the report and writes a new configuration to
+the file 'mixer.config' that can then be used by the mixer.
+
+A basic scenario that uses the mixer as well as the experimental mixer agent
+looks like this:
+
+[image mixer_agent]
+ Interplay of the graphical mixer front end (mixer agent) with the audio mixer.
+
+This scenario is available in the form of the run script at
+_gems/run/mixer_gui_qt_test.run_. In addition to the mixer and mixer agent, it
+features a few more components. We therefore also discuss their roles here.
+The mixer component receives its configuration from the _FS-ROM_ component and
+reports a list of its channels to the report-ROM component. The mixer agent
+accesses the channel-list report as ROM module provided by the report-ROM
+component. It writes the configuration to the file _/config/mixer.config_,
+which is stored by the _config-file-system_ component. The FS-ROM component
+exports each file as ROM module. One of those modules is the _mixer.config_
+that is, in turn, presented as configuration to the mixer component. Each time
+the _mixer.config_ file is altered, the mixer receives a signal, reloads the
+new version of the configuration, and adapts itself accordingly. In return,
+the mixer sends a new report every time its channel list changes. This report
+is consumed by the mixer agent to adjust itself, i.e., to display or remove a
+client widget. All this mechanics is hidden behind a simple GUI dialog. By
+moving a slider, the user generates a new mixer configuration.
+
+
+Copy and paste
+==============
+
+When using Genode as a desktop OS, users need to be able to copy and paste
+text between different subsystems such as guest OSes running in VirtualBox and
+Qt5 applications running directly on Genode.
+
+This integration feature requires two ingredients. First, the respective
+subsystems need to interface their internal clipboard mechanisms (like the
+clipboard of the guest OS) with the Genode world. Second, we need a clipboard
+component that manages the information flows between the subsystems.
+
+*Import/export of clipboard data of subsystems*
+
+From the subsystem's perspective, Genode's clipboard protocol looks as follows:
+
+* A subsystem propagates new clipboard content to the Genode world via a
+ report session with the label "clipboard". Each time its internal clipboard
+ content changes, it issues a report with the new content.
+
+* For importing clipboard content from the Genode world, the subsystem opens
+ a ROM session with the label "clipboard" and registers a signal handler for
+ ROM-changed signals. Upon the reception of such a signal, the subsystem
+ requests the updated ROM content and forwards it to its internal clipboard.
+
+The session labels for the ROM and report sessions are merely a convention
+that should be followed to enable the session routing in a uniform way.
+
+A clipboard report has the following format:
+
+!
+! ... UFT8-encoded and XML-sanitized text ...
+!
+
+*Clipboard component*
+
+The clipboard component is similar to the existing report-ROM server in that
+it provides both a report service and a ROM service. In contrast to the
+report-ROM server, however, all report sessions refer to the same (clipboard)
+report. Reports by different clients override each other. Each time the report
+changes, all ROM clients are notified, which can respond to the notification
+by requesting the updated version of their clipboard ROM module.
+
+*Security considerations*
+
+Given the principle design, the clipboard component could be used to let
+information flow between arbitrary clients. However, in multi-level scenarios,
+we need to constrain the flow of information between different domains. For
+example, we want to prevent a crypto domain from leaking credentials to a
+domain that is connected to the network. To express an information-flow
+policy, the clipboard component has the notion of "domains", which correspond
+to the domains already present in the nitpicker GUI server. Clipboard clients
+are associated with domains via the clipboard configuration:
+
+!
+! ...
+!
+!
+! ...
+!
+
+By default, a clipboard report is propagated solely to clients of the same
+domain as the originator. All other clients will receive an empty clipboard
+ROM module (this enables those subsystems to clear their local clipboard
+selection). To propagate clipboard data across domains, a white list of
+information-flow policies must be defined as follows:
+
+!
+! ...
+!
+!
+!
+! ...
+!
+
+This example defines a policy where data can flow from the work and hobby
+domains to the admin domain but not in the other direction. Furthermore, data
+copied in the hobby domain can be pasted in the work domain but not vice
+versa.
+
+Even though the transport of the actual clipboard content can be subjected to
+the stated information-flow policy, two conspiring clipboard clients can still
+misuse the clipboard to establish a covert channel: Because each time a report
+is generated, a clipboard ROM update is propagated to all clients (some
+receive the actual content whereas some receive an empty clipboard), two
+presumably isolated clients can use those notifications to send bits of
+information. For this reason, we need to limit the bandwidth of those
+notifications. The biggest problem is that the clipboard reports are generated
+by the (untrusted) subsystem software, which can issue reports at an arbitrary
+rate. Ideally, we wish to let the user give its consent for each generated
+clipboard report. But this would interfere with the work flow universally
+expected by users. The clipboard component addresses the problem by
+dynamically incorporating status information of the nitpicker GUI server into
+the information-flow policy:
+
+* The clipboard server accepts reports only when they originate from the
+ domain that is focused by nitpicker. Nitpicker already provides "focus"
+ reports that contain this information. Conveniently, the focus reports
+ already contain the name of the focused domain (in addition to the client's
+ session label). With the correspondence of the clipboard's domains to
+ nitpicker's domains, the clipboard is able to take nitpicker's focus reports
+ into account for the information-flow policy.
+
+* To further limit the rate of artificial clipboard reports, the clipboard
+ component accepts reports only from a domain where a corresponding nitpicker
+ client received user input recently. The term "recently" refers to a
+ reasonable upper bound of the time needed by a guest OS or an application
+ to respond to Control-C or a similar key sequence, i.e., 500 milliseconds.
+ This way, a subsystem can submit new clipboard content only shortly after
+ the user interacted with the subsystem, which is always the case when the
+ user triggers the copy operation. To accommodate this mechanism, nitpicker's
+ focus reports had to be slightly enhanced by a new attribute "active" that is
+ set to "yes" if the user interacted with the domain recently.
+
+As another measure to limit the bandwidth of the covert channel, the clipboard
+server notifies its ROM clients only if their ROM module actually changed.
+This way, not each report from an unrelated domain results in a ROM-changed
+signal but only the one that invalidated the formerly visible clipboard
+content. So the active help of the user is required to transfer bits of
+information.
+
+*Clipboard supporting subsystems*
+
+With the current release, the clipboard protocol has been implemented into
+Qt5 applications and VirtualBox. On VirtualBox, we leverage the shared
+clipboard mechanism provided by the VirtualBox guest additions.
+
+
+Graceful exiting of subsystems
+==============================
+
+In dynamic scenarios like desktop computing, subsystems should be able to
+gracefully exit. For applications manually started via a panel or a shell-like
+command interface (CLI monitor), the user expects the system to free the
+application's resources after the exit of the application. Originally most of
+Genode's runtime environments used to respond to the exit of a child by merely
+printing a message to the log. It was up to the user to manually regain the
+resources by explicitly killing the subsystem afterwards. To make the CLI
+monitor and the graphical launcher more pleasant to use, we enhanced them
+to perform the kill operation automatically once a child exits gracefully.
+
+In many cases, subsystems are assembled out of several components using a
+nested instance of init. E.g., such subsystems are a composition of protocol
+stacks like nit_fb, terminal, ram_fs in addition to the actual application.
+The lifetime of such a composed subsystem mostly depends on one of those
+components (e.g., the noux runtime or VirtualBox VMM). To enable the CLI
+monitor (or the launcher) to automatically respond to an exiting noux
+instance, we need to propagate the exit of the noux component through the
+intermediate init runtime to the CLI monitor. To do that, we extended the
+configuration concept of init with an additional sub node for the ''
+node:
+
+!
+!
+! ...
+!
+
+If the propagate attribute is set to yes, the exit of the respective child
+will result in the exit of the entire init component, including all siblings
+of the exited component. The approach gives us the freedom to define even
+multiple children that may trigger the exit condition of init (by specifying
+an '' node at several '' nodes.
+
+
+Base framework and low-level OS infrastructure
+##############################################
+
+Changes at the system-integration level
+=======================================
+
+Label-dependent session routing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Access-control policies in Genode systems are based on session labels. When a
+server receives a new session request, the session label is passed along with
+the request.
+
+A session label is a string that is assembled by the components that are
+involved with routing the session request from the client along the branches
+of the component tree to the server. The client may specify the least
+significant part of the label by itself. This part gives the parent a hint
+for routing the request. For example, a client may create two file-system
+sessions, one labeled with "home" and one labeled with "bin". The parent may
+take this information into account and route the individual requests to
+different file-system servers. The label is successively superseded (prefixed)
+by additional parts along the chain of components on the route of the session
+request. The first part of the label is the most significant part as it is
+imposed by the component in the intermediate proximity of the server. The last
+part is the least trusted part of the label because it originated from the
+client. Once the session request arrives at the server, the server takes the
+session label as the key to select a server-side policy.
+
+Whereas the use of session labels for selecting server-side policies has
+been a common practice for a long time, label-dependent session routing
+was rarely needed. In most cases, routing decisions were simply based on
+the type of the requested sessions. However, as Genode's system scenarios get
+more sophisticated, label-dependent routing becomes increasingly important.
+As we wished to express the criterion of routing decisions and the
+server-side policy selection in a uniform way, we introduced the following
+common label-matching rules.
+
+Both a '' node in init's routing configuration as well as a
+'' node in the server's configuration can be equipped with the
+following attributes to match session labels:
+
+:'label=""': The session label must perfectly match the specified
+ string.
+
+:'label_prefix=""': The first part of the label must match the
+ specified string.
+
+:'label_suffix=""': The last part of the label must match the
+ specified string.
+
+If no attributes are present, the route/policy matches. The attributes can be
+combined. If any of the specified attributes mismatch, the route/policy is
+neglected.
+
+If multiple '' nodes match in init's routing configuration, the first
+matching rule is taken. So the order of the nodes is important.
+
+If multiple '' nodes match at the server side, the most specific
+policy is selected. Exact matches are considered as most specific, prefixes as
+less specific, and suffixes as least specific. If multiple prefixes or
+suffixes match, the longest is considered as the most specific.
+
+*Note* This change requires slight adaptations of existing configurations
+because the semantics of the original 'label' attribute of server-side policy
+nodes has changed. Originally, the attribute value was taken as a prefix for
+matching the session label. Now, the attribute would be taken as a perfect
+match. The adaptation of existing configurations is as simple as replacing
+"label" by "label_prefix". Since the change tightens the semantics of the
+label attribute, it will not weaken the security of existing policies. In the
+worst case, a server will reject sessions that formerly passed the label
+checks, but not vice versa.
+
+
+New VFS server component
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Genode has traditionally featured a number of file system servers, each
+designed for a specific storage back end. The implementation of new servers
+and features came with the additional effort of maintaining consistent code
+and behavior between server varieties. The VFS server is a solution to this
+redundancy. By building a server around the VFS library, new storage back
+ends need to implement the VFS plugin interface only. This unification is not
+without runtime benefit, as it leads the way to more discretion in component
+composition. The server allows clients to share the burden of plug-ins that
+come with a large consumption of resources, but this potentially reduces
+privacy and can act as covert communication medium. From another perspective,
+clients may host plug-ins to reduce context switches between the file system
+and raw storage, or the VFS server may host high complexity plug-ins to
+maintain low complexity in a security sensitive address space. For the time
+being, the VFS server should be considered a resource multiplexer without
+strong client isolation.
+
+The following two configurations contrast the traditional ram_fs with the VFS
+server.
+
+!
+!
+!
+!
+!
+!
+!
+!
+! ...
+!
+! ...
+!
+
+!
+!
+!
+!
+!
+!
+!
+!
+!
+! ...
+!
+! ...
+!
+
+
+New VFS-local symlink file system
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A goal of the VFS library is to provide declarative file system composition.
+This release adds a symlink built-in to the library, which allows the
+configuration to populate file systems with symlinks.
+
+!
+! ...
+!
+!
+!
+!
+!
+!
+! ...
+!
+
+
+New server for aggregating LOG data to file-system storage
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The fs_log component has been refactored to better express the source of
+logging streams as well as to operate at lower complexity. For each client
+session, the session label is converted to a directory tree with the trailing
+element being the file, to which log messages are written. Logs may also be
+merged using session-policy selectors with a label prefix. See
+_os/src/server/fs_log/README_ for details.
+
+
+New ROM logger component
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The new ROM logger component located at _os/src/app/rom_logger/_ is a simple
+utility to monitor the content of a ROM module. It is meant to be used for
+test automation and during debugging. Each time, the monitored ROM module
+changes, the ROM logger prints its content to the LOG.
+
+
+New ROM filter component
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The new ROM filter component located at _os/src/server/rom_filter/_ provides a
+ROM module that depends on the content of other ROM modules. Its designated
+use is the dynamic switching between configuration variants dependent on the
+state of the system. For example, the configuration of the window decorator
+may be toggled depending on whether nitpicker's X-ray mode is active or not.
+
+
+*Configuration*
+
+The configuration consists of two parts. The first part is the declaration of
+input values that are taken into account. The input values are obtained from
+ROM modules that contain XML-formatted data. Each input value is represented
+by an '' node with a unique 'name' attribute. The 'rom' attribute
+specifies the ROM module to take the input from. If not specified, the value
+of 'name' is used as the ROM name. The type of the top-level XML node can be
+specified via the 'node' attribute. If not present, the top-level XML node is
+expected to correspond to the 'name' attribute.
+
+The second part of the configuration defines the output via an '