version: 16.05

Fixes #1951

README

@@ -10,10 +10,10 @@ the project's official website:
 
 :Official project website for the Genode OS Framework:
 
-  [http://genode.org/documentation/general-overview]
+  [https://genode.org/documentation/general-overview]
 
 The current implementation can be compiled for 8 different kernels: Linux,
-L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, Codezero, and a custom
+L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, seL4, and a custom
 kernel for running Genode directly on ARM-based hardware. Whereas the Linux
 version serves us as development vehicle and enables us to rapidly develop the
 generic parts of the system, the actual target platforms of the framework are
@@ -70,5 +70,5 @@ mailing list. Please feel welcome to join in!
 
 :Genode Mailing Lists:
 
-  [http://genode.org/community/mailing-lists]
+  [https://genode.org/community/mailing-lists]
 

VERSION

@@ -1 +1 @@
-15.05
+16.05

doc/architecture.txt

@@ -1,789 +0,0 @@
-
-                 ====================================
-                 Design of the Genode OS Architecture
-                 ====================================
-
-
-                  Norman Feske and Christian Helmuth
-
-Abstract
-########
-
-In the software world, high complexity of a problem solution comes along with a
-high risk for bugs and vulnerabilities.
-This correlation is particularly perturbing for todays commodity operating
-systems with their tremendous complexity.
-The numerous approaches to increase the user's confidence in the correct
-functioning of software comprise exhaustive tests, code auditing, static code
-analysis, and formal verification.
-Such quality-assurance measures are either rather shallow or they scale badly
-with increasing complexity.
-
-The operating-system design presented in this document focuses on the root of the
-problem by providing means to minimize the underlying system complexity for
-each security-sensitive application individually.
-On the other hand, we want to enable multiple applications to execute on the
-system at the same time whereas each application may have different functional
-requirements from the operating system.
-Todays operating systems provide a functional superset of the requirements of
-all applications and thus, violate the principle of minimalism for each single
-application.
-We resolve the conflict between the principle of minimalism and the versatility
-of the operating system by decomposing the operating system into small
-components and by providing a way to execute those components isolated and
-independent from each other.
-Components can be device drivers, protocol stacks such as file systems and
-network stacks, native applications, and containers for executing legacy
-software.
-Each application depends only on the functionality of a bounded set of
-components that we call _application-specific_trusted_computing_base_(TCB)_.
-If the TCBs of two applications are executed completely _isolated_ and
-_independent_ from each other, we consider both TCBs as minimal.
-
-In practice however, we want to share physical resources between multiple applications
-without sacrificing their independence.
-Therefore, the operating-system design has to enable the assignment of physical
-resources to each application and its TCB to maintain independence from other
-applications.
-Furthermore, rather than living in complete isolation, components require to
-communicate with each other to cooperate.
-The operating-system design must enable components to create other components
-and get them to know each other while maintaining isolation from uninvolved
-parts of the system.
-
-First, we narrow our goals and pose our mayor challenges in Section [Goals and Challenges].
-Section [Interfaces and Mechanisms] introduces our fundamental concepts and
-protocols that apply to each component in the system.
-In Section [Core - the root of the process tree], we present the one component
-that is mandatory part of each TCB, enables the bootstrapping of the system,
-and provides abstractions for the lowest-level resources.
-We exercise the composition of the presented mechanisms by the means of process
-creation in Section [Process creation].
-;Section [Framework infrastructure]
-
-
-Goals and Challenges
-####################
-
-The Genode architecture is designed to accommodate the following types
-of components in a secure manner concurrently on one machine:
-
-:Device  drivers:
-
-  Device drivers translate the facilities of raw physical devices to
-  device-class-specific interfaces to be used by other components.
-  They contain no security policies and provide their services
-  to only one client component per device.
-
-:Services that multiplex resources:
-
-  To make one physical resource (e.g., a device) usable by multiple
-  components at the same time, the physical resource must be translated
-  to multiple virtual resources. For example, a
-  frame buffer provided by a device driver can only be used by one
-  client at the same time. A window system multiplexes this physical
-  resource to make it available to multiple clients. Other examples
-  are an audio mixer or a virtual network hub.
-  In contrast to a device driver, a _resource multiplexer_ deals with multiple
-  clients and therefore, plays a crucial role for maintaining the independence
-  and isolation of its clients from each other.
-
-:Protocol stacks:
-
-  Protocol stacks translate low-level protocols to a higher and more applicable
-  level.
-  For example, a file system translates a block-device protocol to a file
-  abstraction, a TCP/IP stack translates network packets to a socket
-  abstraction, or a widget set maps high-level GUI elements to pixels.
-  Compared to resource multiplexers, protocol stacks are typically an
-  order of magnitude more complex.
-  Protocol stacks may also act as resource multiplexers. In this case however,
-  high complexity puts the independence and isolation of multiple
-  clients at a high risk.
-  Therefore, our design should enable the instantiation of protocol stacks per
-  application.
-  For example, instead of letting a security-sensitive application share one
-  TCP/IP stack with multiple other (untrusted) applications, it could use a
-  dedicated instance of a TCP/IP stack to increase its independence and
-  isolation from the other applications.
-
-:Containers for executing legacy software:
-
-  A _legacy container_ provides an environment for the execution of existing
-  legacy software. This can be achieved by the means of a virtual machine
-  (e.g., a Java VM, a virtual PC), a compatible programming API (e.g., POSIX,
-  Qt), a language environment (e.g., LISP), or a script interpreter.
-  In the majority of cases, we regard legacy software as an untrusted black box.
-  One particular example for legacy software are untrusted legacy device drivers.
-  In this case, the container has to protect the physical hardware from
-  potentially malicious device accesses by the untrusted driver.
-  Legacy software may be extremely complex and resource demanding, for example
-  the Firefox web browser executed on top of the X window system and the Linux
-  kernel inside a virtualized PC.
-  In this case, the legacy container may locally implement sophisticated
-  resource-management techniques such as virtual memory.
-
-:Small custom security-sensitive applications:
-
-  Alongside legacy software, small custom applications implement crucial
-  security-sensitive functionality.
-  In contrast to legacy software, which we mostly regard as untrusted anyway,
-  a low TCB complexity for custom applications is of extreme importance.
-  Given the special liability of such an application, it is very carefully
-  designed to have low complexity and require as little infrastructure as
-  possible.
-  A typical example is a cryptographic component that protects credentials
-  of the user.
-  Such an application does not require swapping (virtual memory), a POSIX API,
-  or a complete C library.
-  Instead, the main objectives of such an application are to avoid as much as
-  possible code from being included in its TCB and to keep its requirements at
-  a minimum.
-
-Our design must be able to create and destroy subsystems that are composed of
-multiple such components.
-The _isolation_ requirement as stated in the introduction raises the
-question of how to organize the locality of name spaces and how to distribute
-access from components to other components within the system.
-The _independence_ requirement demands the assignment of physical resources
-to components such that different applications do not interfere.
-Instead of managing access control and physical resources from a central
-place, we desire a distributed way for applying policy for trading and revocating
-resources and for delegating rights.
-
-
-
-Interfaces and Mechanisms
-#########################
-
-The system is structured as a tree.
-The nodes of the tree are processes.
-A node, for which sub-nodes exist, is called the _parent_ of these sub-nodes
-(_children_).
-The parent creates children out of its own resources and defines
-their execution environment.
-Each process can announce services to its parent.
-The parent, in turn, can mediate such a service to its other children.
-When a child is created, its parent provides the initial contact to the
-outer world via the following interface:
-
-! void exit(int exit_value);
-!
-! Session_capability session(String service_name,
-!                            String args);
-!
-! void close(Session_capability session_cap);
-!
-! int announce(String          service_name,
-!              Root_capability service_root_cap);
-!
-! int transfer_quota(Session_capability to_session_cap,
-!                    String amount);
-
-
-:'exit': is called by a child to request its own termination.
-
-:'session': is called by a child to request a connection to the specified
-  service as known by its parent whereas 'service_name' is the name
-  of the desired service _interface_.
-  The way of resolving or even denying a 'session' request depends on
-  the policy of the parent.
-  The 'args' parameter contains construction arguments for the session
-  to be created.
-  In particular, 'args' contains a specification of resources that the
-  process is willing to donate to the server during the session lifetime.
-
-:'close': is called by a child to inform its parent that the specified
-  session is no longer needed.
-  The parent should close the session and hand back donated
-  resources to the child.
-
-:'announce': is called by a child to register a locally implemented
-  service at its parent. Hence, this child is a server.
-
-:'transfer_quota': enables a child to extend its resource donation
-  to the server that provides the specified session.
-
-We provide a detailed description and motivation for the different functions
-in Sections [Servers] and [Quota].
-
-Servers
-=======
-
-Each process may implement services and announce them via the 'announce'
-function of the parent interface.
-When announcing a service, the server specifies a _root_ capability for
-the implemented service.
-The interface of the root capability enables the parent to create, configure,
-and close sessions of the service:
-
-! Session_capability session(String args);
-!
-! int transfer_quota(Session_capability to_session_cap,
-!                    String amount);
-!
-! void close(Session_capability session_cap);
-
-
-[image announce 60%]
-  Announcement of a service by a child (server).
-  Colored circles at the edge of a component represent remotely accessible
-  objects. Small circles inside a component represent a reference (capability)
-  to a remote object. A cross-component reference to a remote object is
-  illustrated by a dashed arrow. An opaque arrow symbolizes a RPC call/return.
-
-Figure [announce] illustrates an announcement of a service.
-Initially, each child has a capability to its parent.
-After Child1 announces its service "Service", its parent knows the
-root capability of this service under the local name 'srv1_r' and stores
-the root capability with the announced service name in its _root_list_.
-The root capability is intended to be used and kept by the parent only.
-
-[image request 60%]
-  Service request by a client.
-
-When a parent calls the 'session' function of the root interface of a server
-child, the server creates a new client session and returns the corresponding
-'client_session' capability.
-This session capability provides the actual service-specific interface.
-The parent can use it directly or it may pass it to other processes, in
-particular to another child that requested the session.
-In Figure [request], Child2 initiates the creation of a "Service" session
-by a 'session' call at its parent capability (1).
-The parent uses its root list to look up the root capability that matches the
-service name "Service" (2) and calls the 'session' function at the
-server (3).
-Child1 being the server creates a new session ('session1') and returns the
-session capability as result of the 'session' call (4).
-The parent now knows the new session under the local name 'srv1_s1' (5) and
-passes the session capability as return value of Child2's initial 'session'
-call (6).
-The parent maintains a _session_list_, which stores the interrelation between
-children and their created sessions.
-Now, Child2 has a direct communication channel to 'session1' provided by
-the server (Child1) (7).
-
-The 'close' function of the root interface instructs the server to
-destroy the specified session and to release all session-specific resources.
-
-; Mittels 'set_quota' kann der Parent einen Dienst anweisen, die Ressourcennutzung
-; für eine angegebene 'client_session' zu begrenzen. Eine nähere Beschreibung des
-; Ressourcen-Accountings erfolgt in Kapitel [Quota].
-
-[image twolevels 80%]
-  Announcement and request of a service in a subsystem.
-  For simplicity, parent capabilities are not displayed.
-
-Even though the prior examples involved only one parent,
-the announce-request mechanism can be used recursively for tree
-structures of any depth and thus allow for partitioning
-the system into subsystems that can cooperate with each other whereas
-parents are always in complete control over the communication
-and resource usage of their children (and their subsystems).
-
-Figure [twolevels] depicts a nested subsystem on the left.
-Child1 announces its service named "Service" at its parent that, in turn,
-announces a service named "Service" at the Grandparent.
-The service names do not need to be identical.
-Their meaning spans to their immediate parent only and there
-may be a name remapping on each hierarchy level.
-Each parent can decide itself whether to further announce
-services of their children to the outer world or not.
-The parent can announce Child1's service to the grandparent
-by creating a new root capability to a local service that forwards
-session-creation and closing requests to Child1.
-Both Parent and Grandparent keep their local root lists.
-In a second step, Parent2 initiates the creation of a session to
-the service by issuing a 'session' request at the Grandparent (1).
-Grandparent uses its root list to look up the service-providing child (from
-Grandparent's local view) Parent1 (2).
-Parent1 in turn, implements the service not by itself but delegates
-the 'session' request to Child1 by calling the 'session' function
-of the actual "Service" root interface (3).
-The session capability, created by Child1 (4), can now be passed to Parent2
-as return value of nested 'session' calls (5, 6).
-Each involved node keeps the local knowledge about the created session
-such that later, the session can be closed in the same nested fashion.
-
-Quota
-=====
-
-Each process that provides services to other processes consumes resources on
-behalf of it clients.
-Such a server requires memory to maintain session-specific state, processing
-time to perform the actual service function, and eventually further system
-resources (e.g., bus bandwidth) dependent on client requests.
-To avoid denial-of-service problems, a server must not allocate such
-resources from its own budget but let the client pay.
-Therefore, a mechanism for donating resource quotas from the client to the
-server is required.
-Both client and server may be arbitrary nodes in the process tree.
-In the following, we examine the trading of resource quotas within
-the recursive system structure using memory as an example.
-
-When creating a child, the parent assigns a part of its own memory quota
-to the new child.
-During the lifetime of the child, the parent can further transfer
-quota back and forth between the child's and its own account.
-Because the parent creates its children out of its own resources,
-it has a natural interest to correctly manage child quotas.
-When a child requests a session to a service, it can bind a part
-of its quota to the new session by specifying a resource donation
-as an argument.
-When receiving a session request, the parent has to distinct
-three different cases, dependent on where the corresponding server
-resides:
-
-:Parent provides service:
-
-  If the parent provides the requested services by itself,
-  it transfers the donated amount of memory quota from the
-  requesting child's account to its own account to compensate
-  the session-specific memory allocation on behalf of its own
-  child.
-
-:Server is another child:
-
-  If there exists a matching entry in the parent's root list,
-  the requested service is provided by another child (or a
-  node within the child subsystem). In this case, the parent
-  transfers the donated memory quota from the requesting child
-  to the service-providing child.
-
-:Delegation to grandparent:
-
-  The parent may decide to delegate the session request to
-  its own parent because the requested service is provided by
-  a lower node of the process tree.
-  Thus, the parent will request a session on behalf of its child.
-  The grandparent neither knows nor cares about the actual
-  origin of the request and will simply decrease the memory
-  quota of the parent.
-  For this reason, the parent transfers the donated memory
-  quota from the requesting child to its own account before
-  calling the grandparent.
-
-This algorithm works recursively.
-Once, the server receives the session request, it checks if
-the donated memory quota suffices for storing the session-specific
-data and, on success, creates the session.
-If the initial quota donation turns out to be too scarce during
-the lifetime of a session, the client may make further donations
-via the 'transfer_quota' function of the parent interface that
-works analogously.
-
-If a child requests to close a session, the parent must distinguish
-the three cases as above.
-Once, the server receives the session-close request from its parent,
-it is responsible to release all resources that were used for this session.
-After the server releases the session-specific resources, the
-server's quota can be decreased to the prior state.
-However, an ill-behaving server may fail to release those resources by malice
-or caused by a bug.
-
-If the misbehaving service was provided by the parent himself,
-it has the full authority to not hand back session-quota to
-its child.
-If the misbehaving service was provided by the grandparent,
-the parent (and its whole subsystem) has to subordinate.
-If, however, the service was provided by another child and the
-child refuses to release resources, decreasing its quota after
-closing the session will fail.
-It is up to the policy of the parent to handle such a failure either by
-punishing it (e.g., killing the misbehaving server) or by granting more of its
-own quota.
-Generally, misbehavior is against the server's own interests and
-each server would obey the parent's 'close' request to avoid intervention.
-
-
-Successive policy management
-============================
-
-For supporting a high variety of security policies for access control, we
-require a way to bind properties and restrictions to sessions. For example,
-a file service may want to restrict the access to files according to an
-access-control policy that is specific for each client session.
-On session creation, the 'session' call takes an 'args' argument that can be
-used for that purpose. It is a list of tag-value pairs describing the session
-properties. By convention, the list is ordered by attribute priority starting
-with the most important property.
-The server uses these 'args' as construction arguments for the new
-session and enforces the security policy as expressed by 'args' accordingly.
-Whereas the client defines its desired session-construction arguments, each
-node that is incorporated in the session creation can alter these arguments in
-any way and may add further properties.
-This effectively enables each parent to impose any desired restrictions to
-sessions created by its children.
-This concept works recursively and enables each node in the process hierarchy
-to control exactly the properties that it knows and cares about.  As a side
-note, the specification of resource donations as described in the Section
-[Quota] is performed with the same mechanism. A resource donation is a property
-of a session.
-
-[image incremental_restrictions]
-  Successive application of policies at the creation time of a new session.
-
-Figure [incremental_restrictions] shows an example scenario. A user
-application issues the creation of a new session to the 'GUI' server and
-specifies its wish for reading user input and using the string "Terminal" as
-window label (1).
-The parent of the user application is the user manager that introduces
-user identities into the system and wants to ensure that each displayed window
-gets tagged with the user and the executed program. Therefore, it overrides the
-'label' attribute with more accurate information (2). Note that the modified
-argument is now the head of the argument list.
-The parent of the user manager, in turn, implements further policies. In the
-example, Init's policy prohibits the user-manager subtree from reading
-input (for example to disable access to the system beyond official working hours)
-by redefining the 'input' attribute and leaving all other attributes unchanged (3).
-The actual GUI server observes the final result of the successively changed
-session-construction arguments (4) and it is responsible for enforcing the specified
-policy for the lifetime of the session.
-Once a session has been established, its properties are fixed and cannot be changed.
-
-
-Core - the root of the process tree
-###################################
-
-Core is the first user-level program that takes control when starting up the
-system. It has access to the raw physical resources and converts them to
-abstractions that enable multiple programs to use these resources.
-In particular, core converts the physical address space to higher-level
-containers called _dataspaces_.
-A dataspace represents a contiguous physical address space region with an
-arbitrary size (at page-size granularity).
-Multiple processes can make the same dataspace accessible in their
-local address spaces.
-The system on top of core never deals with physical memory pages but
-uses this uniform abstraction to work with memory, memory-mapped I/O
-regions, and ROM areas.
-
-*Note:* _Using only contiguous dataspaces may lead to fragmentation of the_
-_physical address space. This property is, however, only required by_
-_a few rare cases (e.g., DMA transfers). Therefore, later versions of the_
-_design will support non-contiguous dataspaces._
-
-Furthermore, core provides all prerequisites to bootstrap the process tree.
-These prerequisites comprise services for creating processes and threads,
-for allocating memory, for accessing boot-time-present files, and for managing
-address-space layouts.
-Core is almost free from policy. There are no configuration options.
-The only policy of core is the startup of the init process to which core
-grants all available resources.
-
-In the following, we explain the session interfaces of core's services in
-detail.
-
-
-RAM - allocator for physical memory
-===================================
-
-A RAM session is a quota-bounded allocator of blocks from physical memory.
-There are no RAM-specific session-construction arguments.
-Immediately after the creation of a RAM session, its quota is zero.
-To make the RAM session functional, it must be loaded with quota from
-another already existing RAM session, which we call the _reference account_.
-The reference account of a RAM session can be defined initially via:
-!int ref_account(Ram_session_capability ram_session_cap);
-Once the reference account is defined, quota can be transferred back and
-forth between the reference account and the new RAM session with:
-!int transfer_quota(Ram_session_capability ram_session_cap,
-!                   size_t amount);
-Provided, the RAM session has enough quota, a dataspace of a given size
-can be allocated with:
-!Ram_dataspace_capability alloc(size_t size);
-The result value of 'alloc' is a capability to the RAM-dataspace
-object implemented in core. This capability can be communicated to other
-processes and can be used to make the dataspace's physical-memory region
-accessible from these processes.
-An allocated dataspace can be released with:
-!void free(Ram_dataspace_capability ds_cap);
-The 'alloc' and 'free' calls track the used-quota information of the RAM
-session accordingly.
-Current statistical information about the quota limit and the
-used quota can be retrieved by:
-!size_t quota();
-!size_t used();
-Closing a RAM session implicitly destroys all allocated dataspaces.
-
-
-ROM - boot-time-file access
-===========================
-
-A ROM session represents a boot-time-present read-only file.  This may be a
-module provided by the boot loader or a part of a static ROM image. On session
-construction, a file identifier must be specified as a session argument using the
-tag 'filename'.  The available filenames are not fixed but depend on the actual
-deployment. On some platforms, core may provide logical files for special memory
-objects such as the GRUB multiboot info structure or a kernel info page.  The
-ROM session enables the actual read access to the file by exporting the file as
-dataspace:
-!Rom_dataspace_capability dataspace();
-
-
-IO_MEM - memory mapped I/O access
-=================================
-
-With IO_MEM, core provides a dataspace abstraction for non-memory parts of the
-physical address space such as memory-mapped I/O regions or BIOS areas. In
-contrast to a memory block that is used for storing information of which the
-physical location in memory is of no matter, a non-memory object has a special
-semantics attached to its location within the physical address space. Its
-location is either fixed (by standard) or can be determined at runtime, for
-example by scanning the PCI bus for PCI resources.  If the physical location of
-such a non-memory object is known, an IO_MEM session can be created by
-specifying 'base' and 'size' as session-construction arguments.
-The IO_MEM session then provides the specified physical memory area as
-dataspace:
-!Io_mem_dataspace_capability dataspace();
-
-
-IO_PORT - access to I/O ports
-=============================
-
-For platforms that rely on I/O ports for device access, core's IO_PORT service
-enables fine-grained assignment of port ranges to individual processes.
-Each IO_PORT session corresponds to the exclusive access right to a
-port range as specified with the 'io_port_base' and 'io_port_size'
-session-construction arguments. Core creates the new IO_PORT session
-only if the specified port range does not overlap with an already existing
-session. This ensures that each I/O port is driven by only one
-process at a time. The IO_PORT session interface resembles the
-physical I/O port access instructions. Reading from an I/O port
-can be performed via an 8bit, 16bit, or 32bit access:
-!unsigned char  inb(unsigned short address);
-!unsigned short inw(unsigned short address);
-!unsigned       inl(unsigned short address);
-Vice versa, there exist functions for writing to an I/O port via
-an 8bit, 16bit, or 32bit access:
-!void outb(unsigned short address, unsigned char value);
-!void outw(unsigned short address, unsigned short value);
-!void outl(unsigned short address, unsigned value);
-The address argument of I/O-port access functions are absolute
-port addresses that must be within the port range of the session.
-
-
-IRQ - handling device interrupts
-================================
-
-The IRQ service of core provides processes with an interface to
-device interrupts. Each IRQ session corresponds to an attached
-interrupt. The physical interrupt number is specified via the
-'irq_number' session-construction argument. A physical interrupt
-number can be attached to only one session. The IRQ session
-interface provides a blocking function to wait for the next
-interrupt:
-!void wait_for_irq();
-While the 'wait_for_irq' function blocks, core unmasks the
-interrupt corresponding to the IRQ session.
-On function return, the corresponding interrupt line is masked
-and acknowledged.
-
-;*Note:* _The interface of the IRQ service is going to be changed_
-;_with the planed addition of signals to the framework._
-
-
-RM - managing address space layouts
-===================================
-
-RM is a _region manager_ service that allows for constructing address space
-layouts (_region map_) from dataspaces and that provides support for assigning
-region maps to processes by paging the process' threads.
-Each RM session corresponds to one region map. After creating a new RM session,
-dataspaces can be attached to the region map via:
-!void *attach(Dataspace_capability ds_cap,
-!             size_t size=0, off_t offset=0,
-!             bool use_local_addr = false,
-!             addr_t local_addr = 0);
-The 'attach' function inserts the specified dataspace into the region map and
-returns the actually used start position within the region map.
-By using the default arguments, the region manager chooses an appropriate
-position that is large enough to hold the whole dataspace.
-Alternatively, the caller of 'attach' can attach any sub-range of the dataspace
-at a specified target position to the region map by enabling 'use_local_addr'
-and specifying an argument for 'local_addr'. Note that the interface allows for the
-same dataspace to be attached not only to multiple region maps but also multiple
-times to the same region map.
-As the counterpart to 'attach', 'detach' removes dataspaces from the region map:
-!void detach(void *local_addr);
-The region manager determines the dataspace at the specified 'local_addr' (not
-necessarily the start address) and removes the whole dataspace from the region
-map.
-To enable the use of a RM session by a process, we must associate it with
-each thread running in the process. The function
-!Thread_capability add_client(Thread_capability thread);
-returns a thread capability for a _pager_ that handles the page faults of the
-specified 'thread' according to the region map.
-With subsequent page faults caused by the thread, the address-space layout
-described by the region map becomes valid for the process that is executing the
-thread.
-
-
-CPU - allocator for processing time
-===================================
-
-A CPU session is an allocator for processing time that allows for the creation,
-the control, and the destruction of threads of execution.
-There are no session arguments used.
-The functionality of starting and killing threads is provided by two functions:
-!Thread_capability create_thread(const char* name);
-!void kill_thread(Thread_capability thread_cap);
-The 'create_thread' function takes a symbolic thread name (that is only used
-for debugging purposes) and returns a capability to the new thread.
-Furthermore, the CPU session provides the following functions for operating
-on threads:
-!int set_pager(Thread_capability thread_cap,
-!              Thread_capability pager_cap);
-
-!int cancel_blocking(Thread_capability thread_cap);
-
-!int start(Thread_capability thread_cap,
-!          addr_t ip, addr_t sp);
-
-!int state(Thread_capability thread,
-!          Thread_state     *out_state);
-The 'set_pager' function registers the thread's pager whereas 'pager_cap'
-(obtained by calling 'add_client' at a RM session) refers to the RM session to
-be used as the address-space layout.
-For starting the actual execution of the thread, its initial instruction
-pointer ('ip') and stack pointer ('sp') must be specified for the 'start'
-operation.
-In turn, the 'state' function provides the current thread state including
-the current instruction pointer and stack pointer.
-The 'cancel_blocking' function causes the specified thread to cancel a
-currently executed blocking operation such as waiting for an incoming message
-or acquiring a lock. This function is used by the framework for gracefully
-destructing threads.
-
-*Note:* _Future versions of the CPU service will provide means to further control the_
-_thread during execution (e.g., pause, execution of only one instruction),_
-_acquiring more comprehensive thread state (current registers), and configuring_
-_scheduling parameters._
-
-
-PD - providing protection domains
-=================================
-
-A PD session corresponds to a memory protection domain. Together
-with one or more threads and an address-space layout (RM session), it forms a
-process.
-There are no session arguments. After session creation, the PD contains no
-threads. Once a new thread has been created from a CPU session, it can be assigned
-to the PD by calling:
-! int bind_thread(Thread_capability thread);
-
-
-CAP - allocator for capabilities
-================================
-
-A capability is a system-wide unique object identity that typically refers to a
-remote object implemented by a service. For each object to be made remotely
-accessible, the service creates a new capability associated with the local
-object. CAP is a service to allocate and free capabilities:
-! Capability alloc(Capability ep_cap);
-! void free(Capability cap);
-The 'alloc' function takes an entrypoint capability as argument, which is the
-communication receiver for invocations of the new capability's RPC interface.
-
-
-LOG - debug output facility
-===========================
-
-The LOG service is used by the lowest-level system components such as the init
-process for printing debug output.
-Each LOG session takes a 'label' string as session argument,
-which is used to prefix the debug output of this session.
-This enables developers to distinguish multiple producers of debug output.
-The function
-! size_t write(const char *string);
-outputs the specified 'string' to the debug-output backend of core.
-
-
-Process creation
-################
-
-The previous section presented the services implemented by core.
-In this section, we show how to combine these basic mechanisms to create and
-execute a process.
-Process creation serves as a prime example for our general approach to first
-provide very simple functional primitives and then solve complex problems using
-a composition of these primitives.
-We use slightly simplified pseudo code to illustrate this procedure.
-The 'env()' object refers to the environment of the creating process, which
-contains its RM session and RAM session.
-
-:Obtaining the executable ELF binary:
-
-  If the binary is available as ROM object, we can access its data by creating
-  a ROM session with the binary's name as argument and attaching its dataspace
-  to our local address space:
-  !Rom_session_capability file_cap;
-  !file_cap = session("ROM", "filename=init");
-  !Rom_dataspace_capability ds_cap;
-  !ds_cap = Rom_session_client(file_cap).dataspace();
-  !
-  !void *elf_addr = env()->rm_session()->attach(ds_cap);
-
-  The variable 'elf_addr' now points to the start of the binary data.
-
-:ELF binary decoding and creation of the new region map:
-
-  We create a new region map using the RM service:
-  !Rm_session_capability rm_cap;
-  !rm_cap = session("RM");
-  !Rm_session_client rsc(rm_cap);
-  Initially, this region map is empty.
-  The ELF binary contains CODE, DATA, and BSS sections.
-  For each section, we add a dataspace to the region map.
-  For read-only CODE and DATA sections, we attach the corresponding ranges of
-  the original ELF dataspace ('ds_cap'):
-  !rsc.attach(ds_cap, size, offset, true, addr);
-  The 'size' and 'offset' arguments specify the location of the section within
-  the ELF image. The 'addr' argument defines the desired start position at the
-  region map.
-  For each BSS and DATA section, we allocate a read-and-writeable RAM dataspace
-  !Ram_dataspace_capability rw_cap;
-  !rw_cap = env()->ram_session()->alloc(section_size);
-  and assign its initial content (zero for BSS sections, copy of ELF DATA sections).
-  !void *sec_addr = env()->rm_session()->attach(rw_cap);
-  !  ... /* write to buffer at sec_addr */
-  !env()->rm_session()->detach(sec_addr);
-  After iterating through all ELF sections, the region map of the new process
-  is completely initialized.
-
-:Creating the first thread:
-
-  For creating the main thread of the new process, we create a
-  new CPU session from which we allocate the thread:
-  !CPU_session_capability cpu_cap = session("CPU");
-  !Cpu_session_client csc(cpu_cap);
-  !Thread_capability thread_cap = csc.create_thread();
-  When the thread starts its execution and fetches its first instruction, it
-  will immediately trigger a page fault. Therefore, we need to assign a
-  page-fault handler (pager) to the thread. With resolving subsequent page faults, the
-  pager will populate the address space in which the thread is executed with
-  memory mappings according to a region map:
-  !Thread_capability pager_cap = rsc.add_client(thread_cap);
-  !csc.set_pager(thread_cap, pager_cap);
-
-:Creating a protection domain:
-
-  The new process' protection domain corresponds to a PD session:
-  !Pd_session_capability pd_cap = session("PD");
-  !Pd_session_client pdsc(pd_cap);
-
-:Assigning the first thread to the protection domain:
-
-  !pdsc.bind_thread(thread_cap);
-
-:Starting the execution:
-
-  Now that we defined the relationship of the process' region map, its main
-  thread, and its address space, we can start the process by specifying the
-  initial instruction pointer and stack pointer as obtained from the ELF
-  binary.
-  !csc.start(thread_cap, ip, sp);
-
-; supplying the parent capability to the new process
-
-

doc/challenges.txt

@@ -29,13 +29,6 @@ Applications and library infrastructure
   platform. This would allow Chrome to be considered as a secure interface to
   the web for use cases in the high-assurance domain.
 
-:Qemu or Virtual Box on Genode:
-
-  Using Genode as hosting platform for virtual machines running in Qemu or
-  Virtual Box would enable the execution of security-sensitive functions (for
-  example cryptography) with a minimally-complex trusted computing base
-  beside running Windows on the same machine.
-
 :VNC server implementing Genode's framebuffer session interface:
 
   With 'Input' and 'Framebuffer', Genode provides two low-level interfaces
@@ -217,19 +210,6 @@ Device drivers
   decomposition of this solution such that the USB host driver and each USB
   device driver runs in a separate process.
 
-:IOMMU support on the NOVA Hypervisor:
-
-  The NOVA hypervisor is the first open-source microkernel with thorough
-  support for IOMMUs, which principally enables the use of untrusted device
-  drivers alongside sensitive software on one machine. Without an IOMMU, each
-  device driver for a device that operates with DMA, is able to indirectly
-  access the whole physical memory through programming the device. With IOMMU,
-  the physical memory addressable by DMA operations can be restrained per
-  device. The goal of this challenge is to enhance Genode with I/O protection
-  when running on the NOVA kernel. This would clear the way towards reusing
-  complex untrusted device drivers running in dedicated device-driver OS
-  instances.
-
 :I/O Kit:
 
   I/O Kit is the device-driver framework as used by the Darwin operating
@@ -323,22 +303,6 @@ Runtime environments
   removed from the trusted computing base of Android, facilitating the use of
   this mobile OS in high-assurance settings.
 
-:Vancouver VMM for Genode on the NOVA hypervisor:
-
-  Vancouver is the user-level virtual-machine monitor accompanying the NOVA
-  hypervisor. It combines a VT-based CPU virtualization with a rich set of
-  device models to run unmodified guest operating systems at near-native
-  performance. Since NOVA is a supported base platform of Genode, running
-  Vancouver in the dynamic Genode environment has become feasible. By running
-  Vancouver on Genode instead of NOVA's original static userland would open up
-  new use cases where the combination of faithful virtualization with dynamic
-  applications is desired.
-
-  Genode 11.11 introduced the initial integration of Vancouver into Genode.
-  This version of Vancouver is able to bootstrap another kernel (e.g.,
-  Fiasco.OC) within the virtual machine. However, several pieces are missing
-  for reaching the goal of running a fully-fledged Linux OS as guest.
-
 :Runtime for the D programming language:
 
   The D systems programming language was designed to overcome many gripes that
@@ -359,12 +323,11 @@ Platforms
 :Evaluation of MP scheduling models on different Genode base platforms:
 
   Several of Genode's supported base platforms come with multi-processor
-  support, i.e., Linux, NOVA, L4ka::Pistachio, Codezero, and Fiasco.OC. Each of
+  support, i.e., Linux, NOVA, L4ka::Pistachio, and Fiasco.OC. Each of
   these kernels follows a different approach for utilizing multiple CPUs. For
-  example, Linux and Codezero manage the association of threads with CPUs
-  largely transparent for user-level programs. In contrast, NOVA makes the use
-  of multiple CPUs explicit and constraints the modes of IPC interaction of
-  threads running on different CPUs. Furthermore, kernels differ with regard to
+  example, Linux manages the association of threads with CPUs largely
+  transparent for user-level programs - not so for the available microkernels.
+  Furthermore, microkernels differ with reagrd to
   thread migration and scheduling. The goal of this project is to identify ways
   to support the SMP features of the respective kernels at Genode's API level
   such that SMP can be easily utilized by Genode programs in a largely kernel
@@ -400,23 +363,6 @@ Platforms
   Finally, this project has the potential to ignite a further collaboration
   between the HelenOS and Genode communities.
 
-:Support for the seL4 kernel:
-
-  The seL4 kernel developed by NICTA and OK-Labs is the first formally verified
-  microkernel. It runs on the x86 and ARM architectures and supports the
-  execution of a paravirtualized version of Linux on top. Even though seL4 is
-  proprietary technology, a free binary release and the specification of the
-  kernel API has been published early 2011. Being a capability-based kernel,
-  seL4 is in the line of the current-generation L4 kernels alongside NOVA and
-  Fiasco.OC. Genode already supports the latter two kernel, which hints at the
-  feasibility to support seL4 as well. Currently, the seL4 kernel comes with a
-  rather static user land, which is far from utilizing the full potential of
-  the kernel with regard to dynamic resource management. By adapting Genode to
-  seL4, a rich dynamic application workload would become available to this
-  kernel, which could potentially spawn interest in extending the formal
-  verification efforts at NICTA to the Genode system executing dynamic
-  real-world applications.
-
 :Support for the Barrelfish kernel:
 
   [http://barrelfish.org - `Barrelfish] is a so-called multi-kernel OS designed

doc/coding_style.txt

@@ -55,7 +55,7 @@ Identifiers
 * 'Multi_word_identifiers' use underline to separate words.
 * 'CONSTANTS' and template arguments are upper case.
 * Private and protected members of a class begin with an '_'-character.
-* Accessor functions are named after their corresponding attributes:
+* Accessor methods are named after their corresponding attributes:
 
   ! /**
   !  * Request private member variable
@@ -67,6 +67,10 @@ Identifiers
   !  */
   ! void value(int value) { _value = value; }
 
+* Accessors that return a boolean value do not carry an 'is_' prefix. E.g.,
+  a method for requesting the validity of an object should be named
+  'valid()', not 'is_valid()'.
+
 
 Indentation
 ===========
@@ -136,13 +140,13 @@ Braces
   ! {
   !   public:
   !
-  !     void function(void)
+  !     void method(void)
   !     {
   !       ...
   !     }
   ! };
 
-  except for single-line functions.
+  except for one-line functions.
 
 * All other occurrences of open braces (for 'if', 'while', 'do', 'for',
   'namespace', 'enum' etc.) are at the end of a line:
@@ -153,7 +157,8 @@ Braces
   !   ..
   ! }
 
-* Surprisingly, one-line functions should be written on one line.
+* One-line functions should be written on a single line as long as the line
+  length does not exceed approximately 80 characters.
   Typically, this applies for accessor functions.
   If slightly more space than one line is needed, indent as follows:
 
@@ -164,10 +169,10 @@ Braces
 Comments
 ========
 
-Function header
-~~~~~~~~~~~~~~~
+Function/method header
+~~~~~~~~~~~~~~~~~~~~~~
 
-Each public or protected (but no private) function in a header-file should be
+Each public or protected (but no private) method in a header-file should be
 prepended by a header as follows:
 
 ! /**

doc/components.txt

@@ -28,7 +28,7 @@ of them is briefly characterized as follows:
   via core's IO_MEM, IO_PORT, and IRQ services. The functionality of
   the driver is made available to other system components by announcing
   one of Genode's device-independent session interfaces, which are
-  'pci_session', 'framebuffer_session', 'input_session', 'block_session',
+  'platform_session', 'framebuffer_session', 'input_session', 'block_session',
   'audio_out_session', 'log_session', 'nic_session', and 'timer_session'
   (see 'os/include/' for the interface definitions). Those interfaces are
   uniform across hardware platforms and kernel base platforms. Usually,
@@ -67,20 +67,25 @@ repositories. The most predominant repositories hosting device drivers are
 Platform devices
 ================
 
-:'os/src/drivers/platform/': Platform drivers for various ARM boards.
-
-:'os/src/drivers/pci':
-  Implements the PCI-session interface using the PCI controller as found on
-  x86 PC hardware. Using this interface, a client can probe for a particular
-  device and request information about physical device resources (using the
-  'pci_device' interface). I/O resources for MMIO regions, I/O ports, and
-  interrupts can be requested by the provided PCI device abstraction.
+:'os/src/drivers/platform/': Platform drivers for various platforms.
+  On x86, the platform driver uses the PCI controller as found on x86 PC
+  hardware. A client can probe for a particular device and request information
+  about physical device resources (using the 'platform_device' interface). I/O
+  resources for MMIO regions, I/O ports, and interrupts can be requested by the
+  provided device abstraction.
 
 :'os/src/drivers/acpi':
   On x86 platforms that use the APIC (namely Fiasco.OC, NOVA, and hw_x86_64)
-  this simple ACPI parser traverses the ACPI tables and updates interrupt line
-  information of PCI devices within the PCI config space. It uses the pci_drv as
-  a utility started as a child and exports its interface.
+  this simple ACPI parser traverses the ACPI tables and reports device-resource
+  information (e.g., interrupt lines of PCI devices).
+
+:'libports/src/app/acpica':
+  In addition to our ACPI base driver, the acpica component uses the
+  ACPICA library to provide access to dynamic functions like battery
+  states, events (e.g., notebook lid close and power buttons), as well
+  as reset and power off. The componenten reports ACPI events and
+  states as reports and itself responds to system state changes of
+  certain configuration ROMs.
 
 
 UART devices
@@ -88,16 +93,16 @@ UART devices
 
 The UART device drivers implement the UART-session interface.
 
-:'os/src/drivers/uart/pl011':
+:'os/src/drivers/uart/spec/pl011':
   Driver for the PL011 UART as found on many ARM-based platforms.
 
-:'os/src/drivers/uart/i8250':
+:'os/src/drivers/uart/spec/i8250':
   Driver for the i8250 UART as found on PC hardware.
 
-:'os/src/drivers/uart/omap4':
+:'os/src/drivers/uart/spec/omap4':
   Driver for the UART as found on OMAP4-based hardware.
 
-:'os/src/drivers/uart/exynos5':
+:'os/src/drivers/uart/spec/exynos5':
   Driver for the UART as found on Exynos-5-based hardware.
 
 
@@ -112,15 +117,11 @@ input-session interfaces respectively.
   to resolve a dependency from an input session for scenarios where no user
   input is required.
 
-:'os/src/drivers/input/fiasco_ux':
-  Driver for the virtual hardware provided by the user-mode version of the
-  Fiasco kernel.
-
-:'os/src/drivers/input/ps2/x86':
+:'os/src/drivers/input/spec/ps2/x86':
   Driver for the 'i8042' PS/2 controller as found in x86 PCs. It supports both
   mouse (including ImPS/2, ExPS/2) and keyboard.
 
-:'os/src/drivers/input/ps2/pl050':
+:'os/src/drivers/input/spec/ps2/pl050':
   Driver for the PL050 PS/2 controller as found on ARM platforms such as
   VersatilePB. The physical base address used by the driver is obtained at
   compile time from a header file called 'pl050_defs.h'. The version of the
@@ -128,32 +129,37 @@ input-session interfaces respectively.
   is made available to the driver via the SPECS machinery of the Genode build
   system.
 
+:'os/src/drivers/input/spec/imx53':
+  Input driver for Egalaxy touchscreen and Freescale's MPR121
+  capacitative touch buttons on i.MX53.
+
 :'libports/src/drivers/framebuffer/vesa':
   Driver using VESA mode setting on x86 PCs. For more information, please refer
   to the README file in the driver directory.
 
-:'os/src/drivers/framebuffer/pl11x':
+:'os/src/drivers/framebuffer/spec/pl11x':
   Driver for the PL110/PL111 LCD display.
 
-:'os/src/drivers/framebuffer/omap4':
+:'os/src/drivers/framebuffer/spec/omap4':
   Driver for HDMI output on OMAP4 SoCs.
 
-:'os/src/drivers/framebuffer/exynos5':
+:'os/src/drivers/framebuffer/spec/exynos5':
   Driver for HDMI output on Exynos-5 SoCs.
 
-:'os/src/drivers/framebuffer/imx53':
+:'os/src/drivers/framebuffer/spec/imx53':
   Driver for LCD output on i.MX53 SoCs.
 
-:'os/src/drivers/framebuffer/imx53':
-  Driver for touchscreen input on i.MX53 quick start board.
-
-:'os/src/drivers/framebuffer/rpi':
+:'os/src/drivers/framebuffer/spec/rpi':
   Driver for the HDMI output of the Raspberry Pi.
 
-:'os/src/drivers/framebuffer/sdl':
+:'os/src/drivers/framebuffer/spec/sdl':
   Serves as both framebuffer and input driver on Linux using libSDL. This
   driver is only usable on the Linux base platform.
 
+:'dde_linux/src/drivers/framebuffer/intel':
+  Framebuffer driver for Intel i915 compatible graphic cards based on
+  the Linux Intel KMS driver.
+
 :'dde_linux/src/drivers/usb':
   USB driver that makes USB HID and USB storage devices available as input
   sessions and block session respectively. For examples of using this driver,
@@ -165,31 +171,32 @@ Timer drivers
 =============
 
 The timer driver located at 'os/src/drivers/timer' implements the timer-session
-interface. Technically, it is is both a device driver (accessing a timer
+interface. Technically, it is both a device driver (accessing a timer
 device) and a resource multiplexer (supporting multiple timer-session clients
-at the same time). Depending on the base platform, the implementation uses of
+at the same time). Depending on the base platform, the implementation uses
 different time sources. Time sources are either hardware timers, a time source
 provided by the kernel, or a pseudo time source (busy):
 
-:'nova':      NOVA kernel semaphores as time source
-:'codezero':  busy time source
-:'okl4_x86':  PIT as time source
-:'foc':       IPC timeout as time source
-:'fiasco':    IPC timeout as time source
-:'pistachio': IPC timeout as time source
-:'linux':     nanosleep as time source
+:'nova':      NOVA kernel semaphores
+:'okl4_x86':  Programmable Interval Timer (PIT) device
+:'foc':       IPC timeout
+:'fiasco':    IPC timeout
+:'pistachio': IPC timeout
+:'linux':     nanosleep()
+:'hw':        kernel timer
 
 
-Audio output drivers
-====================
+Audio drivers
+=============
 
-All audio-output drivers implement the audio session interface defined at
-'os/include/audio_out_session/'.
+Audio drivers implement the Audio_out session interface defined at
+'os/include/audio_out_session/' for playback and optionally the audio_in
+interface for recording.
 
-:'os/src/drivers/audio_out/linux':
-  Uses ALSA as back-end on the Linux base platform.
+:'os/src/drivers/audio/spec/linux':
+  Uses ALSA as back-end on the Linux base platform and supports only playback.
 
-:'dde_bsd/src/drivers/audio_out':
+:'dde_bsd/src/drivers/audio':
   Sound drivers ported from OpenBSD. Currently, the repository
   includes support for Intel HD Audio as well as for Ensoniq AudioPCI
   (ES1370) compatible sound cards.
@@ -201,21 +208,21 @@ Block drivers
 All block drivers implement the block-session interface defined at
 'os/include/block_session/'.
 
-:'os/src/drivers/sd_card/pl180':
+:'os/src/drivers/sd_card/spec/pl180':
   Driver for SD-cards connected via the PL180 device as found on the PBX-A9
   platform.
 
-:'os/src/drivers/sd_card/omap4':
+:'os/src/drivers/sd_card/spec/omap4':
   Driver for SD-cards connected to the SD-card controller of the OMAP4 SoC.
 
-:'os/src/drivers/sd_card/exynos5':
+:'os/src/drivers/sd_card/spec/exynos5':
   Driver for SD-cards and eMMC connected to Exynos-5-based platforms.
 
-:'os/src/drivers/sd_card/imx53':
+:'os/src/drivers/sd_card/spec/imx53':
   Driver for SD-cards connected to the Freescale i.MX53 platform like the
   Quick Start Board or the USB armory device.
 
-:'os/src/drivers/sd_card/rpi':
+:'os/src/drivers/sd_card/spec/rpi':
   Driver for SD-cards connected to the Raspberry Pi.
 
 :'dde_linux/src/drivers/usb':
@@ -226,6 +233,9 @@ All block drivers implement the block-session interface defined at
 :'os/src/drivers/ahci':
   Driver for SATA disks and CD-ROMs on x86 PCs.
 
+:'os/src/drivers/usb_block':
+  USB Mass Storage Bulk-Only driver using the USB session interface.
+
 
 Network interface drivers
 =========================
@@ -233,14 +243,18 @@ Network interface drivers
 All network interface drivers implement the NIC session interface
 defined at 'os/include/nic_session'.
 
-:'os/src/drivers/nic/linux':
+:'os/src/drivers/nic/spec/linux':
   Driver that uses a Linux tap device as back end. It is only useful on the
   Linux base platform.
 
-:'os/src/drivers/nic/lan9118':
+:'os/src/drivers/nic/spec/lan9118':
   Native device driver for the LAN9118 network adaptor as featured on the
   PBX-A9 platform.
 
+:'os/src/drivers/nic/gem':
+  Device driver for Cadence EMAC PS network adaptor as featured on the
+  Xilinx Zynq.
+
 :'dde_ipxe/src/drivers/nic':
   Device drivers ported from the iPXE project. Supported devices are Intel
   E1000 and pcnet32.
@@ -256,12 +270,19 @@ defined at 'os/include/nic_session'.
 General-purpose I/O drivers
 ===========================
 
-:'os/src/drivers/gpio/omap4':
+:'os/src/drivers/gpio/spec/omap4':
   Driver for accessing the GPIO pins of OMAP4 platforms.
 
-:'os/src/drivers/gpio/imx53':
+:'os/src/drivers/gpio/spec/imx53':
   Driver for accessing the GPIO pins of i.MX53 platforms.
 
+:'os/src/drivers/gpio/spec/rpi':
+  Driver for accessing the GPIO pins of Raspberry Pi platforms.
+
+:'os/src/drivers/gpio/spec/exynos5':
+  Driver for accessing the GPIO pins of Exynos4 platforms, e.g.,
+  Odroid-X2.
+
 
 Resource multiplexers
 #####################
@@ -368,13 +389,26 @@ Separate components:
 :'os/src/server/log_terminal':
   Adapter for forwarding terminal output to a LOG session.
 
-:'libports/src/server/fs_log':
+:'os/src/server/fs_log':
   Adapter that writes LOG messages to files on a file system.
 
 :'demo/src/server/nitlog':
   Provides a LOG session, printing log output on screen via a nitpicker
   session.
 
+:'os/src/app/rom_logger':
+  The rom_logger component requests a ROM session and writes the
+  content of the ROM dataspace to the LOG.
+
+:'os/src/server/rom_filter':
+  The ROM filter provides a ROM module that depends on the content of
+  other ROM modules steered by the filter configuration, e.g., dynamic
+  switching between configuration variants dependent on the state of
+  the system.
+
+:'os/src/server/vfs':
+  A file-system server using the VFS library and plugins as backend.
+
 :'os/src/server/log_terminal':
   Forwards terminal output to a LOG session.
 
@@ -411,6 +445,12 @@ Separate components:
   A service that implements both the report session interface and the ROM
   session interface. It reflects incoming reports as ROM modules.
 
+:'os/src/server/clipboard':
+  This component is both a report service and a ROM service. The
+  clients of the report service can issue new clipboard content, which
+  is then propagated to the clients of the ROM service according to a
+  configurable information-flow policy.
+
 :'ports/src/app/openvpn':
   OpenVPN enables access to remote network resources through a secure tunnel
   by providing an encrypted connection to a remote host. It is plugged between
@@ -429,9 +469,6 @@ Libraries:
 :'libports/lib/mk/libc':
   C runtime ported from FreeBSD.
 
-:'libports/lib/mk/libc_log':
-  Redirects the standard output of the libc to Genode's LOG session interface.
-
 :'libports/lib/mk/libc_lwip_nic_dhcp':
   Translates the BSD socket API to a NIC session using the lwIP stack.
 
@@ -447,13 +484,6 @@ Libraries:
 :'libports/lib/mk/libc_fuse_ext2':
   Accesses files on a block device that contains an ext2 file system.
 
-:'libports/lib/mk/libc_fs':
-  Allows libc-using programs to access the Genode file-system infrastructure
-  using the POSIX file API.
-
-:'libports/lib/mk/libc_block':
-  Accesses a block session as a virtual block device.
-
 :'libports/lib/mk/libc_terminal':
   Connects the standard input and output from/to Genode's terminal session
   interface.

doc/contributions.txt

@@ -13,7 +13,7 @@ should be documented but isn't? Or the documentation contains errors with
 regard to content or spelling? Please let us know by raising the issue at the
 genode-main mailing list:
 
-:[http://genode.org/community/mailing-lists - Genode mailing lists]:
+:[https://genode.org/community/mailing-lists - Genode mailing lists]:
 
 If you are interested in getting your hands dirty with working on the Genode
 code base or authoring additional documentation, you are more than welcome.
@@ -31,9 +31,9 @@ Alternatively, you may like to have a look at our road map and future
 challenges to see the big picture of our developments and to get inspiration
 for your own activities:
 
-:[http://genode.org/about/road-map]: Road Map
+:[https://genode.org/about/road-map]: Road Map
 
-:[http://genode.org/about/challenges]: Future Challenges
+:[https://genode.org/about/challenges]: Future Challenges
 
 Once you settled on a specific topic to work on, it is a good idea to get
 acquainted with the work flow and tools used by the project. The following
@@ -81,7 +81,7 @@ Genode's source code follows certain time-tested conventions regarding the
 coding style and code pattern, which are important to us. The coding style
 is described in the following document:
 
-:[http://genode.org/documentation/developer-resources/coding_style]:
+:[https://genode.org/documentation/developer-resources/coding_style]:
   Coding Style Guidelines
 
 We know from experience that for new developers, adhering the coding style can

doc/getting_started.txt

@@ -64,12 +64,11 @@ different kernels such as L4/Fiasco, L4ka::Pistachio, OKL4, and NOVA. Those
 kernels largely differ in terms of feature sets, build systems, tools, and boot
 concepts. To relieve you from dealing with those peculiarities, Genode provides
 you with an unified way of using them. For each kernel platform, there exists
-a dedicated directory called 'base-<platform>'. Within this directory, you will
-find a 'Makefile', which automates the task of downloading the source codes of
-the kernel and interfacing the kernel with Genode. Just change to the
-respective 'base-<platform>' directory and issue:
+a dedicated description file that enables the 'prepare_port' tool to fetch and
+prepare the designated 3rd-party sources. Just issue the following command
+within the toplevel directory of the Genode source tree:
 
-! make prepare
+! ./tool/ports/prepare_port <platform>
 
 Note that each 'base-<platform>' directory comes with a 'README' file, which
 you should revisit first when exploring the base platform. Additionally, most
@@ -77,10 +76,10 @@ you should revisit first when exploring the base platform. Additionally, most
 respective 'doc/' subdirectories.
 
 For the VESA driver on x86, the x86emu library is required and can be
-downloaded and prepared by invoking the following command from within the
-'libports' directory:
+downloaded and prepared by again invoking the 3rd-party sources preparation
+tool:
 
-! make prepare PKG=x86emu
+! ./tool/ports/prepare_port x86emu
 
 Now that the base platform is prepared, the 'create_builddir' tool can be used
 to create a build directory for your platform of choice by giving the platform
@@ -92,7 +91,7 @@ steps are required:
 
 # Download the kernel:
   ! cd <genode-dir>
-  ! make -C repos/base-okl4 prepare
+  ! ./tool/ports/prepare_port okl4
 # Create a build directory
   ! ./tool/create_builddir okl4_x86 BUILD_DIR=build.okl4
 # Uncomment the following line in 'build.okl4/etc/build.conf'

doc/news.txt

@@ -4,6 +4,231 @@
                                ===========
 
 
+Genode OS Framework release 16.05 | 2016-05-27
+##############################################
+
+| With version 16.05, the Genode API receives a fundamental revision.
+| The list of further improvements ranges from the introduction of Rust,
+| over improved GDB support, to a profound update of many device drivers
+| and ACPI features.
+
+The current release marks the most profound API revision in the project's
+history. The new API is designed to reinforce the best practices
+for implementing Genode components. It is the result of countless
+experiments and the practical experiences made while developing over hundred
+genuine components during the past ten years.
+
+The introduction of the new API prompted us to rework our documentation.
+In particular, Genode 16.05 is accompanied with a new edition of the
+"Genode Foundations" book that incorporates all architectural changes and
+interface modifications of the past year.
+
+The second focus of the current release is the major update of device
+drivers. All the drivers that we ported from the Linux kernel correspond
+now to Linux version 4.4.3. Those drivers comprise the Intel wireless
+stack, the Intel graphics driver, the USB drivers, and the TCP/IP stack.
+The updated OpenBSD-based audio driver corresponds to OpenBSD 5.9.
+
+Apart from the revision of the base framework and device drivers, Genode
+gains the ability to use the Rust programming language, makes many ACPI
+features accessible, and allows the use of the GNU debugger with the
+64-bit version of the NOVA hypervisor.
+
+The complete story behind these and many more changes is covered by the
+[http:/documentation/release-notes/16.05 - release documentation of version 16.05...]
+
+
+How Genode came to RISC-V | 2016-03-22
+######################################
+
+| Our new article provides a look behind the scenes of porting Genode to
+| the RISC-V hardware architecture.
+
+The experience report
+[http:/documentation/articles/riscv - How Genode came to RISC-V] complements
+our recent
+[http:/documentation/release-notes/16.02#New_support_for_the_RISC-V_CPU_architecture - announcement]
+about Genode's added RISC-V support with in-depth technical information.
+It briefly introduces the parts of the instruction set architecture (ISA) that
+were most relevant for the porting work, presents various challenges we
+encountered, and explains how we overcame them.
+
+The article is written with two target audiences in mind: People interested in
+practical experiences with RISC-V, and developers who aspire to port Genode
+to new CPU architectures.
+[http:/documentation/articles/riscv - Read the article...]
+
+
+Genode OS Framework release 16.02 | 2016-02-26
+##############################################
+
+| Genode 16.02 introduces the RISC-V hardware architecture to the framework,
+| enables the secure pass-through of USB devices to virtual machines, and
+| updates the Muen separation kernel and the seL4 microkernel.
+
+In contrast to the feature-oriented previous release, the new version focuses
+on diverse topics around low-level platform support. First, there is the
+addition of a new hardware architecture. With the addition of RISC-V,
+we anticipate future trustworthy open-source hardware platforms.
+
+Second, as the major functional addition motivated by Genode's use as
+day-to-day OS, the new version adds the ability to assign USB devices to
+virtual machines in a dynamic yet secure way. This clears the way to cover
+many typical desktop work-flows with a Genode-based system.
+
+With respect to the framework's underlying kernels, we are happy to
+announce the update of the Muen separation kernel to version 0.7 and the
+update of the seL4 kernel to version 2.1. The new version of Muen comes with
+welcome work-flow improvements. In fact, the separation kernel can now be
+targeted by Genode's automation tools in the same uniform way as all the other
+base platforms.
+
+An in-depth coverage of these and many more improvements is provided by the
+[http:/documentation/release-notes/16.02 - release documentation of version 16.02...]
+
+
+Road Map for 2016 | 2016-01-15
+##############################
+
+| We finalized the road map for 2016, which is primarily focused on extending
+| the community of users.
+
+After having passed the point where a few enthusiasts use Genode as
+their day-to-day OS, it is time to extend the user base beyond
+the inner circle of developers. The road map outlines the plan to make Genode
+appealing to two target audiences, namely system builders and a narrow group
+of privacy-considerate end users. Hence, the overall theme of 2016 is to
+help a growing community to leverage the full potential of Genode.
+
+The new road map is available at the [http:/about/road-map - road-map page].
+
+
+Genode at FOSDEM 2016 | 2016-01-12
+##################################
+
+| There are four Genode-related talks scheduled at this year's FOSDEM,
+| covering the USB Armory, seL4, the Nix package manager, and Genode
+| as desktop OS.
+
+[https://fosdem.org/2016 - FOSDEM] is the worlds biggest gathering of
+open-source and free-software enthusiasts. It takes place during 30 and 31 of
+January in Brussels. This year, Genode will show a strong presence again. On
+Saturday, Emery, Martin, and Norman will contribute to the
+[https://fosdem.org/2016/schedule/track/microkernels/ - microkernel devroom].
+On Sunday, we have the opportunity to present the current state of Genode as
+desktop OS at the desktops devroom. The summary of the Genode-related parts of
+the FOSDEM schedule is as follows.
+
+Saturday 10:40 *An exploration of the seL4 kernel from Genode's perspective*
+_Microkernel devroom (K.4.601)_
+[https://fosdem.org/2016/schedule/event/microkernels_genode_sel4/ - abstract...]
+
+Saturday 14:10 *Porting Nix to Genode - Package management without a canonical file system*
+_Microkernel devroom (K.4.601)_
+[https://fosdem.org/2016/schedule/event/microkernels_genode_nix/ - abstract...]
+
+Saturday 15:55 *Genode's TrustZone demo on the USB Armory*
+_Microkernel devroom (K.4.601)_
+[https://fosdem.org/2016/schedule/event/microkernels_genode_usb_armory/ - abstract...]
+
+Sunday 10:20 *Genode as Desktop OS*
+_Desktops devroom (K.4.401)_
+[https://fosdem.org/2016/schedule/event/genode_as_a_desktop_os/ - abstract...]
+
+
+The story behind Genode's TrustZone demo on the USB Armory | 2015-12-08
+#######################################################################
+
+| Our latest article provides a look behind the scenes of the
+| development of Genode's support for the USB Armory platform.
+
+The [http://inversepath.com/usbarmory - USB Armory] is a computer in the form
+of a USB stick. It normally runs Linux. But thanks to the ARM TrustZone
+capabilities of the device, it is possible to run Genode behind the back of
+Linux. This is useful for shielding sensitive information like cryptographic
+keys from Linux by exposing it to Genode only and thereby drastically reducing
+the attack surface. Even in the event Linux gets compromised, e.g., by a
+vulnerability in the USB stack, the secrets remain protected.
+
+The article "The story behind Genode's TrustZone demo on the USB Armory"
+presents the adventurous story behind enabling this scenario. The biggest challenge
+was splitting the hardware platform into two worlds while maintaining the
+full functionality of Linux. The article goes on to explain the interplay
+between the secure world (Genode) and the normal world (Linux). Furthermore,
+it provides all the pointers needed to reproduce the scenario.
+[http:/documentation/articles/usb_armory - Read the article...]
+
+
+Genode OS Framework release 15.11 | 2015-11-30
+##############################################
+
+| The primary focus of version 15.11 is the use of Genode as a desktop
+| OS. It vastly improves the GUI and audio stacks, features the port of Intel
+| KMS from Linux, extends the support for the USB Armory and Xilinx Zynq-7000,
+| and introduces new file-system infrastructure such as a VFS server.
+
+Whereas the previous release marked the point where the very first user adopted
+Genode as day-to-day OS, we maintained the direction to create a Genode-based
+desktop OS. Most improvements of the new version are related to this goal:
+The GUI and audio stacks have become much more modular, dynamic, and flexible.
+With a new copy-and-paste mechanism, we added a universally expected
+desktop-integration feature in a unique way that mitigates the misuse of the
+clipboard as a covert communication mechanism. Those higher-level features
+are complemented with profound low-level device-driver improvements, most
+noteworthy the addition of the Intel KMS driver. This driver allows us to
+drive multiple displays and switch screen resolutions on the fly.
+
+What high- and low-level components have in common, is the use of Genode's
+uniform configuration concept, which solves a variety of configuration
+problems with a single low-complexity mechanism. It allows us to modify
+all kinds of system configurations - ranging from the wireless driver
+to the style of window decoration - live by merely editing and saving
+text files.
+
+Even though the majority of improvements are attributed to the use of
+Genode as desktop OS, the release also covers other areas.
+Xilinx Zynq-7000 has been added to the supported platforms, TrustZone on
+the USB Armory received a lot of attention, and a new VFS server makes
+Genode's file-system infrastructure much more flexible.
+
+These and many more topics are covered in detail by the
+[http:/documentation/release-notes/15.11 - release documentation of version 15.11...]
+
+
+Genode OS Framework release 15.08 | 2015-08-31
+##############################################
+
+| Version 15.08 marks the starting point of Genode used as day-to-day
+| operating system, which underlines the maturity and scalability of the
+| framework. A further highlight is the ability to execute Genode on
+| top of the Muen separation kernel.
+
+Since the first release of Genode seven years ago, we dreamed of being able
+to use our OS technology as the underlying platform for our day-to-day
+computing needs. With the current version, the day has come: One of
+Genode's core developers has made the switch and others plan to follow
+soon. Hence, the use of Genode as day-to-day OS is the underlying
+theme of most improvements seen in the new version. It addresses
+long-standing deficiencies of the kernel-memory management of the NOVA kernel
+and Genode's custom kernel platform, extends the framework's
+system-monitoring and file-system abilities, and significantly improves the
+integration of VirtualBox with Genode.
+
+The second highlight of version 15.08 is the ability to execute Genode
+system scenarios on top of the Muen separation kernel. Compared to
+microkernels, Muen takes the ambition to reduce kernel complexity to an
+extreme. Written in the safe implementation language SPARK and with a code
+complexity of merely 5,000 lines, it lends itself to be high assuring about
+its correct behavior. From Genode's point of view, Muen represents an
+additional target architecture of the framework's custom base-hw kernel. The
+component isolation enforced by base-hw and the static isolation boundaries
+enforced by Muen represent two lines of defense for protecting
+security-critical system functions from untrusted components.
+
+More details about all the improvements are provided by the
+[http:/documentation/release-notes/15.08 - release documentation of version 15.08...]
+
+
 Genode OS Framework release 15.05 | 2015-05-26
 ##############################################
 

doc/porting_guide.txt

@@ -396,7 +396,7 @@ at _ports/run/dosbox.run_.
 First, we specify the components that need to be built
 
 ! set build_components {
-!   core init drivers/audio_out drivers/framebuffer drivers/input
+!   core init drivers/audio drivers/framebuffer drivers/input
 !   drivers/pci drivers/timer server/tar_fs app/dosbox
 ! }
 ! build $build_components
@@ -429,7 +429,7 @@ Nextm we provide the scenario's configuration 'config':
 !   <default-route>
 !     <any-service> <parent/> <any-child/> </any-service>
 !   </default-route>
-!   <start name="audio_out_drv">
+!   <start name="audio_drv">
 !     <resource name="RAM" quantum="6M"/>}
 !     <provides><service name="Audio_out"/></provides>
 !   </start>
@@ -466,7 +466,7 @@ components and application of the scenario, including DosBox.
 Thereafter we declare all boot modules:
 
 ! set boot_modules {
-!   core init timer audio_out_drv fb_drv ps2_drv ld.lib.so
+!   core init timer audio_drv fb_drv ps2_drv ld.lib.so
 !   libc.lib.so libm.lib.so
 !   lwip.lib.so libpng.lib.so stdcxx.lib.so sdl.lib.so
 !   pthread.lib.so zlib.lib.so dosbox dosbox.tar
@@ -1137,7 +1137,7 @@ Even though Genode encourages writing native device drivers, this task sometimes
 becomes infeasible. Especially if there is no documentation available for a
 certain device or if there are not enough programming resources at hand to
 implement a fully fledged driver. Examples of ported drivers can be found in
-the 'dde_linux', 'dde_oss', and 'dde_ipxe' repositories.
+the 'dde_linux', 'dde_bsd', and 'dde_ipxe' repositories.
 
 In this chapter we will exemplary discuss how to port a Linux driver for an ARM
 based SoC to Genode. The goal is to execute driver code in user land directly on

doc/release_notes-14-05.txt

@@ -811,7 +811,7 @@ are mapped to VFS directories. For example
 !   ...
 !   <config>
 !     ...
-!     <libc> <vfs> <dir name="ram"> <fs label="ram" /> </vfs> </libc>
+!     <libc> <vfs> <dir name="ram"> <fs label="ram" /> </dir> </vfs> </libc>
 !     <share host="/ram/miezekatze" guest="miezekatze" />
 !     ...
 !   </config>

doc/release_notes-15-05.txt

@@ -12,10 +12,10 @@ Version 15.05 represents the most substantial release in the history of Genode.
 It is packed with profound architectural improvements, new device drivers, the
 extension of the supported base platforms, and a brand new documentation.
 
-With the new documentation introduced in Section [Comprehensive architectural
-documentation], the project reaches a mile stone. On our mission to find the
-right architectural abstractions, the past years had a strong research focus.
-We conducted countless of experiments, gathered experience with highly diverse
+With the new documentation introduced in Section [Comprehensive architectural documentation],
+the project reaches a mile stone. On our mission to find the right
+architectural abstractions, the past years had a strong research focus. We
+conducted countless of experiments, gathered experience with highly diverse
 hardware platforms and kernels, and explored application scenarios. Our target
 audience used to be technology enthusiasts. Now that we have reached a point
 where the architecture is mature, it is the time to invite a wider audience,
@@ -66,7 +66,7 @@ completely written from scratch:
 
 The book is published under the Creative Commons Attribution + ShareAlike
 License (CC-BY-SA) and can be downloaded as
-[http://genode.org/documentation/genode-foundation-15-05.pdf - PDF document].
+[http://genode.org/documentation/genode-foundations-15-05.pdf - PDF document].
 
 It first presents the motivation behind our project, followed by a thorough
 description of the Genode OS architecture. The conceptual material is
@@ -74,7 +74,7 @@ complemented with practical information for developers and a discussion of
 framework internals. The second part of the book serves as a reference of
 Genode's programming interfaces.
 
-[http://genode.org/documentation/genode-foundation-15-05.pdf - Download the book (PDF)...]
+[http://genode.org/documentation/genode-foundations-15-05.pdf - Download the book (PDF)...]
 
 In the upcoming weeks, we plan to update the documentation section of the
 genode.org website with the new material. Until then, we hope you find the

doc/release_notes-15-08.txt

@@ -0,0 +1,791 @@
+
+
+              ===============================================
+              Release notes for the Genode OS Framework 15.08
+              ===============================================
+
+                               Genode Labs
+
+
+
+The version 15.08 marks the beginning of Genode as day-to-day OS as one of the
+project's core developers switched to using Genode/NOVA on his machine,
+stressing the OS infrastructure we created over the course of the last seven
+years. Thanks to components like VirtualBox, the Noux runtime for GNU software,
+the Linux wireless stack and Rump-kernel-based file systems, the transition
+went actually much smoother than expected. So other members of the team plan
+to follow soon. Section [Genode as day-to-day operating system] gives an
+overview of the taken approach. Genode's use as general-purpose OS provided
+the incentive for most of the improvements featured by the current release,
+starting with the addressing of the long-standing kernel-memory management
+deficiencies of the NOVA kernel (Section [NOVA kernel-resource management]),
+over enhancements of Genode's tracing and file-system facilities, to vast
+improvements of the guest-host integration of VirtualBox when running on
+Genode.
+
+The release is accompanied with a second line of work led by our friends
+at Codelabs: Enabling Genode to run on top of their Muen separation
+kernel as described in Section [Genode on top of the Muen Separation Kernel].
+Muen is a low-complexity kernel for the 64-bit x86 architecture that
+statically partitions the machine into multiple domains. In contrast to
+microkernels like the ones already supported by Genode, the assignment
+of physical resources (such as memory, CPU time, and devices) happens at
+system-integration time. Since an isolation kernel does not have to deal
+with dynamic resource management at runtime, it is less complex than
+a general-purpose microkernel. This makes it relatively easy to reason about
+its strong isolation properties, which, in turn, makes it attractive for
+high-assurance computing. With Genode being able to run within a Muen
+domain, the rich component infrastructure of Genode can be combined with
+the strong isolation guarantees of Muen.
+
+
+Genode on top of the Muen Separation Kernel
+###########################################
+
+_This section was written by Adrian-Ken Rueegsegger and Reto Buerki who_
+_conducted the described line of work independent from Genode Labs._
+
+After completing our x86_64 port of the Genode base-hw kernel, which was
+featured in the
+[http://genode.org/documentation/release-notes/15.05#Principal_support_for_the_64-bit_x86_architecture - previous release (15.05)],
+we immediately started working on our main goal: running a Genode system as
+guest on the Muen Separation Kernel (SK). This would enable the Muen platform
+to benefit from the rich ecosystem of Genode.
+
+For those who have not read the 15.05 Genode release notes, [http://muen.sk - Muen]
+is an Open-Source microkernel, which uses the [http://spark-2014.org/ - SPARK]
+programming language to enable light-weight formal methods for high assurance.
+The 64-bit x86 kernel, currently consisting of a little over 5'000 LOC, makes
+extensive use of the latest Intel virtualization features and has been formally
+proven to contain no runtime errors at the source-code level.
+
+The new 'hw_x86_64_muen' platform, as the name implies, extends the 'hw_x86_64'
+base-hw kernel by replacing the PIC and timer drivers with paravirtualized
+variants.
+
+In contrast to other kernels supported by Genode, the architecture with Muen is
+different in the sense that the entire 'hw_x86_64_muen' Genode system runs as
+guest VM in VMX non-root mode on the SK. From the perspective of Muen, Genode
+is executed on top of the kernel like any other guest OS without special
+privileges.
+
+[image muen_system_overview]
+  Genode running on top of the Muen Separation Kernel alongside other subjects
+
+This loose coupling of Muen and Genode base-hw enables the robust combination
+of a static, low-complexity SK with a feature-rich and extensive OS framework.
+The result is a flexible platform for the construction of component-based
+high-assurance systems.
+
+People interested in giving the 'hw_x86_64_muen' platform a spin can find a
+small tutorial at _repos/base-hw/doc/x86_64_muen.txt_.
+
+
+NOVA kernel-resource management
+###############################
+
+For several years, the NOVA kernel has served as Genode's primary base
+platform on x86. The main reasons for this choice are: the kernel provides -
+among the supported x86 kernels - the richest feature set like the support of
+IOMMUs, virtualization, and SMP. It also offers a clean design and a stable
+kernel interface. The available kernel-interface specification and the
+readable and modern source base are a pleasure to work with. Hence, Genode
+Labs is able to fully commit to the maintenance and further evolution of this
+kernel.
+
+Nevertheless, since the beginning, the vanilla kernel lacks one essential
+feature to reliably host Genode as user-land, namely the proper management of
+the memory used by the kernel itself (in short kernel-memory management). In
+the past, we already extended the kernel to free up kernel resources when
+destroying kernel objects, e.g., protection domains and page-tables, threads,
+semaphores, and portals. Still, on Genode/NOVA, a component may trigger
+arbitrary kernel-memory consumption during RPC by delegating memory,
+capabilities, or by creating other components via Genode's core component. If
+the kernel memory gets depleted, the kernel panics with an "Out of memory"
+message and the entire Genode scenario stops.
+
+In principal, the consumption of kernel memory can be deliberately provoked by
+a misbehaving (greedy) component. But also during the regular day-to-day usage
+of Genode, can such a situation occur when the system is used in a highly
+dynamic fashion. For example, compiling and linking source code within the
+noux environment constantly creates and destroys protection domains, threads,
+and memory mappings. Our nightly test of compiling Genode within noux triggers
+this condition every once in a while.
+
+The main issue here is that the consumption of kernel memory is not accounted
+by Genode. The kernel interface does not support such a feature. Kernels like
+seL4 as well as Genode's custom base-hw kernel show how this problem can be
+solved.
+
+To improve the current situation - where the overall kernel memory is a fixed
+amount - we extended NOVA in the following ways: First, the NOVA kernel
+accounts any kernel memory consumption per protection domain. Second, each
+process has a limited amount of kernel-memory quota it can use. Last, the
+kernel detects when the quota limit of a protection domain is reached.
+
+If the third condition occurs, the kernel stops the offending thread and
+(optionally) notifies a handler thread. This so called out-of-memory (OOM)
+handler thread receives information about the current situation and may
+respond to it in the following ways:
+
+* Stop the thread of the depleted protection domain, or
+* Transfer kernel-memory quota between protection domains (upgrading the limit
+  if desired), or
+* Free up kernel memory if possible, e.g., revoke memory delegations, which
+  can be re-created.
+
+We implemented the steps above inside the NOVA kernel and extended Genode's
+core component to handle such OOM situations. All system calls beside the IPC
+call/reply may now return an error code upon depletion of the quota. Most of
+these system calls can solely be performed by core and are handled inside
+core's NOVA-specific platform code.
+
+In the case of IPC call/reply operations, we desired to handle OOM cases
+transparently to Genode user-level components. Therefore, each thread in
+Genode/NOVA now gets constructed with an OOM IPC portal attached. This portal
+is served by the pager thread in core and is traversed on OOM occurrences
+during IPC operations. If a pager thread receives such an OOM IPC, it decodes
+the involved IPC sender and IPC receiver and locates the appropriate
+core-internal paging objects. The currently implemented out-of-memory policy
+tries to upgrade the quota. If this is not possible, an attempt to revoke
+memory mappings from the OOM-causing protection domain is made. This
+implicitly frees-up some kernel memory (e.g., mapping nodes). If none of the
+responses suffices, the handler stops the OOM-causing thread and writes a
+message to the system log.
+
+The current policy implementation constitutes a rather rough heuristic, which
+may not suffice under all circumstances. In the future, we would like to
+specify a distinct policy per component, e.g. depending on prior known memory
+usage patterns. For example, some components follow well-known usage patterns
+and therefore a fixed upper quota limit can be specified. Other components are
+highly dynamic and desire quota upgrades on demand. There are many more
+combinations imaginable.
+
+Our current plan is to collect more experience over the next months with this
+new kernel mechanism. Based on our observations, we may externalize such
+policy decisions and possibly make them configurable per component.
+
+The current implementation however, already avoids the situation that the
+kernel goes out of service if a single component misbehaves
+kernel-memory-wise.
+
+
+Genode as day-to-day operating system
+#####################################
+
+At the beginning of June, Genode reached the probably most symbolic milestone
+in the project's history: Norman - one of the core developers - replaced his
+Linux-based working environment with a Genode-based system. This system is
+composed of the following ingredients:
+
+[image turmvilla_scenario]
+
+The machine used is a Lenovo Thinkpad X201. We settled on this five-year-old
+machine for several reasons. First, it is a very solid platform with a nice
+form factor. Second, it features Intel's AMT (Active Management Technology),
+which is handy to obtain low-level system logs in the case something goes
+wrong. Third, refurbished machines of this type can be obtained for as little
+as 200 EUR. Finally, an older machine reinforces the need for good performance
+of the operating system. So it creates a natural incentive for Norman to find
+and address performance bottlenecks.
+
+Our modified version of the NOVA microhypervisor is the used kernel.
+
+The user interface is based on our custom GUI stack including the nitpicker
+GUI server as well as the window manager and its companion components
+(decorator, layouter, pointer) we introduced in
+[http://genode.org/documentation/release-notes/14.08#New_GUI_architecture - version 14.08].
+The display is driven by the VESA driver. User input is handled by the PS/2
+driver for handling the laptop keyboard and trackpoint, and the USB driver for
+handling an externally connected keyboard and mouse.
+
+Network connectivity is provided by our port of the Intel Wireless stack that
+we introduced with the version
+[http://genode.org/documentation/release-notes/14.11#Intel_wireless_stack - 14.11].
+
+Our custom AHCI driver provides access to the physical hard disk. File-system
+access is provided by our
+[http://genode.org/documentation/release-notes/14.02#NetBSD_file_systems_using_rump_kernels - Rump-kernel-based file-system server].
+
+A simple Genode shell called CLI monitor allows the user to start and kill
+subsystems dynamically. Initially, the two most important subsystems are
+VirtualBox and Noux.
+
+VirtualBox executes a GNU/Linux-based guest OS that we refer to as "rich OS".
+The rich OS serves as a migration path from GNU/Linux to Genode. It is used
+for all tasks that cannot be accomplished directly on Genode yet. At the
+beginning of the transition, the daily routine still very much depends on the
+rich OS. By moving more and more functionality over to the Genode world, we
+will eventually be able to make the rich OS obsolete step by step. Thanks to
+VirtualBox' excellent host-guest-integration features, the VirtualBox window
+can be dynamically resized and the guest mouse cursor integrates seamlessly
+with Genode's pointer. VirtualBox is directly connected to the wireless
+network driver. So common applications like Firefox can be used.
+
+The noux runtime allows us to use command-line-based GNU software directly on
+Genode. Coreutils and Bash are used for managing files. Vim is used for
+editing files. Unlike the rich OS, the noux environment has access to the
+Genode partition of the hard disk. In particular, it can be used to update the
+Genode system. It has access to a number of pseudo files that contain status
+information of the underlying components, e.g., the list of wireless access
+points. Furthermore, it has limited access to the configuration interfaces of
+the base components. For example, it can point the wireless driver to the
+access point to use, or change the configuration of the nitpicker GUI server
+at runtime.
+
+As a bridge between the rich OS and the Genode world, we combine VirtualBox'
+shared-folder mechanism with Genode's VFS infrastructure. The shared folder is
+represented by a dedicated instance of a RAM file system, which is mounted in
+both the VFS of VirtualBox and the VFS of noux.
+
+As evidenced by Norman's use since June, the described system setup is
+sufficient to be productive. So other members of the Genode team plan to
+follow in his footsteps soon. At the same time, the continued use of the
+system from day to day revealed a number of shortcomings, performance
+limitations, and rough edges, which we eventually eliminated. It goes without
+saying that this is an ongoing effort. Eating our own dog food forces us to
+address the right issues to make the daily life more comfortable.
+
+Feature-wise the switch to Genode motivated three developments, namely the
+enhancement of Genode's CLI monitor, the improvement of the window manager,
+and the creation of a CPU-load monitoring tool.
+
+
+Interactive management of subsystem configurations
+==================================================
+
+The original version of CLI monitor obtained the configuration data of its
+subsystems at start time via the Genode::config mechanism. But for managing
+complex scenarios, the config node becomes very complex. Hence, it is
+preferable to have a distinct file for each subsystem configuration.
+
+The new version of CLI monitor scans the directory '/subsystems' for files
+ending with ".subsystem". Each file has the same syntax as the formerly used
+subsystem nodes. This change has the welcome implication that subsystem
+configurations can be changed during the runtime of the CLI monitor, e.g., by
+using a concurrently running instance of noux with access to the _subsystems/_
+directory. This procedure has become an essential part of the daily work flow
+as it enables the interactive evolution of the Genode system.
+
+
+Window-management improvements
+==============================
+
+To make the window manager more flexible while reducing its complexity at the
+same time, we removed the formerly built-in policy hosting the decorator and
+layout components as children of the window manager. Those components are no
+longer child components but siblings. The relationship of the components is
+now solely expressed by the configuration of their common parent, i.e., init.
+This change clears the way to dynamically replace those components during
+runtime (e.g., switching between different decorators).
+
+To improve the usability of the windowed GUI, we enabled the layouter to
+raise windows on click and to let the keyboard focus follow the pointer.
+Furthermore, the window manager, the decorator, and the floating window
+layouter became able to propagate the usage of an alpha channel from the
+client application to the decorator. This way, the decorator can paint the
+decoration elements behind the affected windows, which would otherwise be
+skipped. Consequently, partially transparent windows can be properly displayed.
+
+
+CPU-load monitoring
+===================
+
+During daily system use, we started to wish to know in detail where the CPU
+cycles are spent. For example, the access of a file by the rich OS involves
+several components, including the guest OS itself, VirtualBox, rump_fs (file
+system), part_blk (partition access), ahci_drv (SATA device access), core, and
+NOVA. Investigating performance issues requires a holistic view of all those
+components. For this reason, we enhanced our existing tracing infrastructure
+(Section [Enhanced tracing facilities]) to allow the creation of CPU-load
+monitoring tools. The first tool in this category is the graphical CPU-load
+monitor located at _gems/app/cpu_load_display/_, which displays a timeline of
+the CPU load where each thread is depicted with a different color. Thanks to
+this tool, we have become able to explore performance issues in an interactive
+way. In particular, it helped us to identify and resolve a long-standing
+inaccuracy problem in our low-level timer service.
+
+
+Base framework and low-level OS infrastructure
+##############################################
+
+Improved audio support
+======================
+
+In the previous release, we replaced our old audio driver with a new one that
+provided the same audio-out session interface. Complementing the audio-out
+session, we are now introducing a new audio-in session interface that can be
+used to record audio frames. It is modeled after the audio-out interface in
+the way how it handles the communication between the client and the server. It
+uses shared memory in the form of the Audio_in::Stream to transport the frames
+between the components. A server component captures frames and puts them into
+a packet queue, which is embedded in the Audio_in::Stream. The server
+allocates packets from this queue to store the recorded audio frames. If the
+queue is already full, the server will override already allocated packets and
+will notify the client by submitting an 'overrun' signal. The client has to
+cope with this situation, e.g., by consuming packets more frequently. A client
+can install a signal handler to respond to a progress signal, which is sent by
+the server when a new Audio_in::Packet has been submitted to the packet queue.
+For now, all audio-in server components only support one channel (left)
+although the audio-in session interface principally supports multiple
+channels.
+
+The _dde_bsd_ audio_drv is the first and currently only audio driver component
+that was extended to provide the audio-in session. To express this fact, the
+driver was renamed from _audio_out_drv_ to _audio_drv_. In contrast to its
+playback functionality, which is enabled by default, recording has to be
+enabled explicitly by setting the configuration attribute 'recording' to
+'yes'. If the need arises, playback may be disabled by setting 'playback' to
+'no'. In addition, it is now possible to configure the driver by adjusting the
+mixer in the driver's configuration node. For the time being, the interface as
+employed by the original OpenBSD mixer utility is used.
+
+The following snippet shows how to enable and configure recording on a
+Thinkpad X220 where the headset instead of the internal microphone is used as
+source:
+
+! <start name="audio_drv">
+!   <resource name="RAM" quantum="8M"/>
+!   <provides>
+!     <service name="Audio_out"/>
+!     <service name="Audio_in"/>
+!   </provides>
+!   <config recording="yes">
+!     <mixer field="outputs.master" value="255"/>
+!     <mixer field="record.adc-0:1_source" value="sel2"/>
+!     <mixer field="record.adc-0:1" value="255"/>
+!   </config>
+! </start>
+
+In addition to selecting the recording source, the playback as well as the
+recording volume are raised to the maximum. Information about all available
+mixers and settings in general may be obtained by specifying the 'verbose'
+attribute in the config node.
+
+The enriched driver is accompanied by a simple monitor application, which
+directly plays back all recorded audio frames and shows how to use the
+audio-in session. It can be tested by executing the
+_repos/dde_bsd/run/audio_in.run_ run script.
+
+There are also changes to the audio-out session itself. The length of a period
+was reduced from 2048 to 512 samples to accommodate for a lower latency when
+mixing audio-out packets. A method for invalidating all packets in the queue
+was also added.
+
+
+File-system infrastructure
+==========================
+
+Unlike traditional operating systems that rely on a global name space for
+files, each Genode component has a distinct view on files. Many low-level
+components do not even have the notion of files. Whereas traditional operating
+systems rely on a virtual file system (VFS) implemented in the OS kernel,
+Genode's VFS has the form of a library that can optionally be linked to a
+component. The implementation of this library originated from the noux runtime
+introduced in version
+[http://genode.org/documentation/release-notes/11.02#Noux_-_an_execution_environment_for_the_GNU_userland - 11.02],
+and was later integrated into our C runtime in version
+[http://genode.org/documentation/release-notes/14.05#Per-process_virtual_file_systems - 14.05].
+With the current release, we take the VFS a step further by making it
+available to components without a C runtime. Thereby, low-complexity
+security-sensitive components such as CLI monitor become able to benefit from
+the powerful VFS infrastructure.
+
+The VFS itself received a welcome improvement in the form of private RAM file
+systems. A need for process-local storage motivated a conversion of the
+existing ram_fs server component to an embeddable VFS file system. This
+addition to the set of VFS plugins enables components to use temporary file
+systems without relying on the resources of an external component.
+
+
+Unified networking components
+=============================
+
+Having had a good experience with our Block::Driver implementation, which
+wraps the block-session interface and takes care of the packet-stream
+handling, thus easing the implementation of driver and other block components,
+we observed that this approach did not provide enough flexibility for
+NIC-session servers. For example, NIC servers are bi-directional and when a
+network packet arrives the server has to make sure that there are enough
+resources available to dispatch the network packet to the client. This has to
+be done because the server must never block, e.g., by waiting for allocations
+to succeed or for an empty spot in the packet queue of a client. Therefore,
+such a non-blocking NIC server needs to validate all preconditions for
+dispatching the packet in advance and, if they cannot be met, drop the network
+packet.
+
+In order to implement this kind of behavior, NIC-session servers must have
+direct access to the actual NIC session. For this reason, we removed the
+Nic::Driver interface from Genode and added a Nic::Session_component that
+offers common basic packet-stream-signal dispatch functionality. Servers may
+now inherit from this component and implement their own policy.
+
+We adjusted all servers that implement NIC sessions to the new interface
+(dde_ipxe, wifi, usb, nic_bridge, OpenVPN, ...), and thereby unified all
+networking components within Genode.
+
+
+Enhanced tracing facilities
+===========================
+
+Recent Genode-based system scenarios like the one described in Section
+[Genode as day-to-day operating system] consist of dozens of components that
+interact with each other. For reasoning about the behaviour of such scenarios
+and identifying effective optimization vectors, tools for gathering a holistic
+view of the system are highly desired.
+
+With the introduction of our light-weight
+[http://genode.org/documentation/release-notes/13.08#Light-weight_event_tracing - event-tracing facility]
+in version 13.08, we laid the foundation for such tools. The current release
+extends core's TRACE service with the ability to obtain statistics about CPU
+utilization. More specifically, it enables clients of core's TRACE service to
+obtain the execution times of trace subjects (i.e., threads). The execution
+time is delivered as part of the 'Subject_info' structure. In addition to the
+execution time, the structure delivers the information about the affinity of
+the subject with a physical CPU.
+
+At the current stage, the feature is available solely on NOVA since this is
+our kernel of choice for using Genode as our day-to-day OS. On all other base
+platforms, the returned execution times are 0. To give a complete picture of
+the system's threads, the kernel's idle threads (one per CPU) are featured as
+trace subjects as well. Of course, idle threads cannot be traced but their
+corresponding trace subjects allow TRACE clients to obtain the idle time of
+each CPU.
+
+By obtaining the trace-subject information in periodic intervals, a TRACE
+client is able to gather statistics about the CPU utilization attributed to
+the individual threads present (or no longer present) in the system. One
+instance of such a tool is the new trace-subject reporter located at
+_os/src/app/trace_subject_reporter_. It acts as a TRACE client, which delivers
+the gathered trace-subject information in the form of XML-formatted data to a
+report session. This information, in turn, can be consumed by a separate
+component that analyses the data. In contrast to the low-complexity
+trace-subject reporter, which requires access to the privileged TRACE services
+of core, the (potentially complex) analysing component does not require access
+to core's TRACE service. So it isn't as critical as the trace-subject monitor.
+The first representative of a consumer of trace-subject reports is the
+CPU-load display mentioned in Section [CPU-load monitoring] and depicted in
+Figure [nano3d].
+
+In addition to the CPU-monitoring additions, the tracing facilities received
+minor refinements. Up to now, it was not possible to trace threads that use a
+CPU session other than the component's initial one. A specific example is
+VirtualBox, which employs several CPU sessions, one for each priority. This
+problem has been solved by associating the event logger of each thread with
+its actual CPU session. Consequently, the tracing mechanism has become able to
+trace VirtualBox, which is pivotal for our further optimizations.
+
+
+Low-complexity software rendering functions
+===========================================
+
+Our ambition to use Genode as our day-to-day OS raises the need for custom
+graphical applications. Granted, it is principally possible to base such
+applications on Qt5, which is readily available to native Genode components.
+However, for certain applications like status displays, we prefer to avoid the
+dependency on an overly complex GUI tool kit. To accommodate such
+applications, Genode hosts a small collection of low-complexity graphics
+functions called painters. All of Genode's low-complexity graphical components
+such as nitpicker, launchpad, window decorator, or the terminal are based on
+this infrastructure.
+
+With the current release, we extend the collection with two new painters
+located at _gems/include/polygon_gfx_. Both draw convex polygons with an
+arbitrary number of points. The shaded-polygon painter interpolates the color
+and alpha values whereas the textured-polygon painter applies a texture to the
+polygon. The painters are accompanied by simplistic 3D routines located at
+_gems/include/nano3d/_ and a corresponding example (_gems/run/nano3d.run_).
+
+[image nano3d]
+
+With the nano3d demo and our new CPU load display, the screenshot above shows
+two applications that make use of the new graphics operations.
+
+
+Device drivers
+##############
+
+Completing the transition to the new platform driver
+====================================================
+
+Until now, the platform driver on x86-based machines was formed by the ACPI
+and PCI drivers. The ACPI driver originally executed the PCI driver as a slave
+(child) service. The ACPI driver parsed the ACPI tables and provided the
+relevant information as configuration during the PCI-driver startup. We
+changed this close coupling to the more modern and commonly used
+[http://genode.org/documentation/release-notes/14.02#New_session_interface_for_status_reporting - report_rom mechanism].
+
+When the new ACPI driver finishes the ACPI table parsing, it provides the
+information via a report to any interested and registered components. The
+report contains among other the IRQ re-routing information. The PCI driver is
+a component, which - according to its session routing configuration - plays
+the role of a consumer of the ACPI report.
+
+With this change of interaction of ACPI and PCI driver, the policy for devices
+must be configured solely at the PCI driver and not at the ACPI driver. The
+syntax, however, stayed the same as introduced with release 15.05.
+
+Finally, the PCI driver 'pci_drv' got renamed to 'platform_drv' as already
+used on most ARM platforms. All files and session interfaces containing
+PCI/pci in the names were renamed to Platform/platform. The x86 platform
+interfaces moved to _repos/os/include/platform/x86/_ and the implementation of
+the platform driver to _repos/os/src/drivers/platform/x86/_.
+
+An example x86 platform configuration snippet looks like this:
+
+!<start name="acpi_drv" >
+! <resource .../>
+! <route>
+!  ...
+!  <service name="Report"> <child name="acpi_report_rom"/> </service>
+! </route>
+!</start>
+!
+!<start name="acpi_report_rom" >
+! <binary name="report_rom"/>
+! <resource .../>
+! <provides> <service name="ROM" /> <service name="Report" /> </provides>
+! <config>
+!  <rom> <policy label="platform_drv -> acpi" report="acpi_drv -> acpi"/> </rom>
+! </config>
+! <route> ... </route>
+!</start>
+!
+!<start name="platform_drv" >
+! <resource name="RAM" quantum="3M" constrain_phys="yes"/>
+! <provides> <service name="Platform"/> </provides>
+! <route>
+!  <service name="ROM">
+!   <if-arg key="label" value="acpi"/> <child name="acpi_report_rom"/>
+!  </service>
+!  ...
+! </route>
+! <config>
+!  <policy label="ps2_drv"> <device name="PS2"/> </policy>
+!  <policy label="nic_drv"> <pci class="ETHERNET"/> </policy>
+!  <policy label="fb_drv"> <pci class="VGA"/> </policy>
+!  <policy label="wifi_drv"> <pci class="WIFI"/> </policy>
+!  <policy label="usb_drv"> <pci class="USB"/> </policy>
+!  <policy label="ahci_drv"> <pci class="AHCI"/> </policy>
+!  <policy label="audio_drv"> <pci class="AUDIO"/> <pci class="HDAUDIO"/> </policy>
+! </config>
+!</start>
+
+In order to unify and simplify the writing of run scripts, we added the
+commonly used platform configuration to the file
+_repos/base/run/platform_drv.inc_. This file may be included by any test run
+script in order to setup a default platform driver configuration.
+
+In addition, the snippet provides the following functions:
+'append_platform_drv_build_components', 'append_platform_drv_config' and
+'append_platform_drv_boot_modules'. The functions add necessary information to
+the 'build_components', 'config' and 'boot_modules' run variables. The
+_platform_drv.inc_ also contains the distinction between various ARM/x86
+platforms and includes the necessary pieces. Hence, run scripts are largely
+relieved from platform-specific peculiarities.
+
+The body of an example run script looks like this:
+
+! set build_components { ... }
+!
+! source ${genode_dir}/repos/base/run/platform_drv.inc
+! append_platform_drv_build_components
+!
+! build $build_components
+!
+! create_boot_directory
+!
+! set config { ... }
+!
+! append_platform_drv_config
+!
+! append config { ... }
+!
+! install_config $config
+!
+! append_platform_drv_boot_modules
+!
+! build_boot_image $boot_modules
+!
+! run_genode_until ...
+
+
+BCM57cxx network cards
+======================
+
+During Hack'n Hike 2015, we had access to a server that featured a Broadcom
+network card. Therefore Guido Witmond performed the first steps to enable
+Broadcom's BCM 57cxx cards. With this preliminary work in place, we were
+quickly able to perform the additional steps required to add BCM 57cxx support
+to Genode.
+
+
+VESA driver refinements
+=======================
+
+The VESA driver now reports the frame buffer's line width instead of the
+visible width to the client. This fixes a possible distortion if these widths
+differ, at the cost that content in the right-most area might be invisible in
+such cases.
+
+
+VirtualBox
+##########
+
+Policy-based mouse pointer
+==========================
+
+In the previous release, we implemented support for the transparent
+integration of the guest mouse pointer with nitpicker via the VirtualBox guest
+additions and the vbox_pointer component, which is capable of rendering
+guest-provided mouse-pointer shapes. Now, we extended vbox_pointer by a
+policy-based configuration that allows the selection of ROMs containing the
+actual mouse shape based on the nitpicker session label or domain. With this
+feature in place, it is possible to integrate several VirtualBox instances as
+well as dedicated pointer shapes for specific components. To see the improved
+vbox_pointer in action give _run/vbox_pointer_ a shot.
+
+
+Dynamic adaptation to screen size changes
+=========================================
+
+VirtualBox now notifies the guest operating system about screen-size changes
+(for example if the user resizes a window, which shows the guest frame
+buffer). The VirtualBox guest additions can use this information to adapt the
+guest frame buffer to the new size.
+
+
+SMP support
+===========
+
+Guest operating systems can now use multiple virtual CPUs, which are mapped to
+multiple host CPUs. The number of virtual CPUs can be configured in the
+'.vbox' file.
+
+
+Preliminary audio support
+=========================
+
+At some point, the use of VirtualBox as a stop-gap solution for using Genode
+as everyday OS raises the need to handle audio. With this release, we address
+this matter by enabling preliminary audio support in our VirtualBox port. A
+back end that uses the audio-out and audio-in sessions to playback and record
+sound samples has been added. It disguises itself as the OSS back end that is
+already used by vanilla VirtualBox. Since Genode pretends to be FreeBSD in the
+eyes of VirtualBox (because Genode's libc is based on FreeBSD's libc), the
+provisioning of an implementation of the OSS back end as used on FreeBSD host
+systems is the most natural approach. The audio support is complemented by
+adding the necessary device models for the virtual HDA as well as the AC97
+devices to our VirtualBox port.
+
+For now, it is vital to have the guest OS configure the virtual device in a
+way that considers the current implementation. For example, we cannot
+guarantee distortion-free playback or recording if the guest OS uses a period
+that is too short, typically 10ms or less. There are also remaining issues
+with the mixing/filtering code in VirtualBox. Therefore, we bypass it to
+achieve better audio quality. As a consequence, the device model of the VM has
+to use the same sample rate as is used by the audio-out and audio-in sessions
+(44.1kHz).
+
+Enabling audio support is done be adding
+! <AudioAdapter controller="HDA" driver="OSS" enabled="true"/>
+to the .vbox file manually or configuring the VM accordingly by using the GUI.
+
+
+Platforms
+#########
+
+Execution on bare hardware (base-hw)
+====================================
+
+Bender chain loader on base-hw x86_64
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+On Intel platforms, we use the Bender chain loader from the
+[https://github.com/alex-ab/morbo - Morbo multiboot suite] to detect available
+COM ports of PCI plug-in cards, the AMT SOL device, or as fall back the
+default comport 1. The loader stores the I/O port information of the detected
+cards into the BIOS data area (BDA), from where it is retrieved by core on
+boot and subsequently used for logging. With this release, we added the BDA
+parsing to base-hw on x86-64 and enabled the feature in the run tool. As a
+prerequisite, we had to fix an issue in bender triggered by the loading of
+only one (large) multi-boot kernel. Consequently, its binary in
+_tool/boot/bender_ was updated.
+
+
+Revised page-table handling
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+One of the main advantages of the base-hw platform is that the memory trading
+concept of Genode is universally applied even with regard to kernel objects.
+For instance, whenever a component wants to create a thread, it pays for the
+thread's stack, UTCB, and for the corresponding kernel object. The same
+applies to objects needed to manage the virtual address space of a component
+with the single exception of page tables.
+
+Normally, when the quota, which was donated by a component to a specific
+service, runs out, the component receives an exception the next time it tries
+to invoke the service. The component can respond by upgrading the respective
+session quota. However, in the context of page-fault resolution, this is
+particularly difficult to do. The allocation and thereby the shortage of
+memory becomes evident only when the client produces a page fault. Therefore,
+there is no way to inform the component to upgrade its session quota before
+resolving the fault.
+
+Instead of designing a sophisticated protocol between core and the other
+components to solve this problem, we decided to simplify the current
+page-fault resolution by using a static set of page-tables per component.
+Formerly, page tables were dynamically allocated from core's memory allocator.
+Now, an array of page tables gets allocated during construction of a
+protection domain. When a component runs out of page tables, all of its
+mappings get flushed, and the page tables are populated from scratch. This
+change greatly simplifies the page-table handling inside of base-hw.
+
+
+Dynamic interrupt mode setting on x86_64
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+On x86-based hardware, user-level device drivers have become able to specify
+the trigger mode and polarity of the interrupts when requesting an IRQ
+session. On ARM, those session parameters are ignored. This change enables the
+x86_64 platform to support devices, which use arbitrary trigger modes and
+polarity settings, e.g., AHCI on QEMU and real hardware.
+
+
+Fiasco.OC
+=========
+
+Genode's device-driver support when using the Fiasco.OC kernel as base
+platform received an upgrade.
+
+First, principle support for the Raspberry Pi was added. To make this platform
+useful in practice, a working USB driver is important. I.e., the network
+interface is connected via USB. Hence the USB driver got enabled for
+Fiasco.OC, too. As a result, Genode's software stack can now be used on the
+Raspberry Pi by using either our custom base-hw kernel or Fiasco.OC.
+
+Second, support for the Odroid-X2 platform using the Exynos4412 SoC was added,
+which includes the drivers for clock management (CMU), power management
+(PMU) as well as USB.
+
+Thanks to Reinier Millo Sánchez and Alexy Gallardo Segura for having
+contributed this line of work.
+
+
+Removal of deprecated features
+##############################
+
+We dropped the support for the *ARM Versatile Express* board from the Genode
+source tree to relieve our automated testing infrastructure from supporting a
+platform that remained unused for more than two years.
+
+The device driver environment kit (DDE Kit) was originally intended as a
+common API among the execution environments of ported user-level device
+drivers. However, over the course of the past years, we found that this
+approach could not fulfill its promise while introducing a number of new
+problems. We reported our experiences in the release notes of versions
+[http://genode.org/documentation/release-notes/12.05#Re-approaching_the_Linux_device-driver_environment - 12.05] and
+[http://genode.org/documentation/release-notes/14.11#Roundup - 14.11].
+To be able to remove the DDE-Kit API, we reworked the USB driver, our port of
+the Linux TCP/IP stack, and the wireless driver accordingly.
+

doc/release_notes-16-02.txt

@@ -0,0 +1,652 @@
+
+
+              ===============================================
+              Release notes for the Genode OS Framework 16.02
+              ===============================================
+
+                               Genode Labs
+
+
+
+With version 16.02, we add RISC-V to Genode's supported CPU architectures,
+enable the secure pass-through of individual USB devices to virtual machines,
+and update the support for the Muen and seL4 kernels.
+
+Trustworthy hardware becomes an increasingly pressing problem. With each new
+generation of today's commodity hardware comes a dramatic increase of
+complexity, the addition of proprietary companion processors, and opaque
+firmware blobs. Even with a perfectly secure operating system, the user's
+privacy and security remains at risk as there is no way to assess the
+trustworthiness of our underlying hardware. RISC-V is a new hardware
+architecture that tries to overcome this problem by the means of open source
+and transparency. It is designed to scale from micro controllers to
+general-purpose computers, and to be both synthesizable as FPGA softcores and
+implementable in ASICs. The prospect of a scalable and trustworthy open-source
+hardware platform motivated us to add RISC-V to Genode's supported CPU
+architectures. Section [New support for the RISC-V CPU architecture] gives a
+brief overview of this line of work.
+
+Thanks to the growing number of our regular developers using Genode as day to
+day OS, we create a natural incentive to address typical desktop-OS work
+flows. In particular, the new version comes with the ability to assign
+individual USB devices to VirtualBox instances. Conceptually, this looks like
+a relatively straight-forward feature. But as discussed in Section
+[Assignment of USB devices to virtual machines], we had to overcome a number of
+challenging problems caused by the inherently dynamic nature of USB-device
+hot-plugging. Also on the account of day-to-day computing, the GUI stack
+received welcomed usability improvements like keyboard shortcuts for certain
+window-management operations.
+
+With respect to Genode's underlying base platforms, we are happy to announce
+the updates of the Muen and seL4 kernels. The Muen separation kernel received
+an update to version 0.7, which accommodates Genode's regular work flows (via
+run scripts) much better than the previous version. As described in Section
+[Muen separation kernel], this change clears the way to subject Muen to
+Genode's regular automated tests. The seL4 kernel represents an exciting
+playground as a future base platform for Genode. We have updated the kernel to
+version 2.1, which prompted us to fundamentally revisit the low-level resource
+management of Genode on this kernel. A summary of this undertaking is presented
+in Section [seL4 version 2.1].
+
+According to the [http:/about/road-map - road map], we originally planned to
+revise the framework API in this release. Even though this topic is
+[https://github.com/genodelabs/genode/issues/1832 - very actively pursued], we
+decided to not rush it. We find it important to provide a smooth migration path
+from the old API to the new one. Determining the best path is actually trickier
+than revising the API, though. To let our decisions settle a bit, we postpone
+the transition to the upcoming release.
+
+
+Assignment of USB devices to virtual machines
+#############################################
+
+As a migration strategy for running Genode on a daily basis, using VirtualBox
+to execute a feature-rich OS is vital. In release
+[http://genode.org/documentation/release-notes/15.05#USB-device_pass-through_support - 15.05],
+we added USB pass-through support to VirtualBox by enabling its integrated USB
+proxy service. Since we use the open-source edition of VirtualBox, we were
+merely able to use the OHCI device model and were therefore limited to using
+USB 1.x devices in low and full speed mode only. To make matters worse, when
+using the OHCI controller model, it is difficult if not impossible to access
+USB mass-storage devices. Usually, VirtualBox facilitates the EHCI or xHCI
+device models for the pass-through of storage devices. Unfortunately, those
+models are only available as a proprietary extension, which cannot be used by
+our VirtualBox port.
+
+Having support for the pass-through of high-speed and super-speed USB devices
+is a must in such controller models. Therefore, we either have to implement
+these models ourselves or port existing ones from another VMM or emulator to
+fill the gap. We went for porting existing models first because device-model
+development from scratch could end up being time consuming if we want to
+guarantee them to work with a variety of different OS drivers.
+
+
+QEMU xHCI device model
+----------------------
+
+QEMU features a NEC xHCI (UPD720200) device model that works well with Windows
+guests. For this reason, we decided to give porting this device model a shot.
+We applied the DDE approach and started by creating a QEMU emulation
+environment so that only the bare minimum amount of source code needed to be
+taken from the QEMU sources. It came down to a handful of source files, mainly
+the USB core and the xHCI device model files. We iteratively extended the
+emulation environment until the QEMU sources compiled and linked fine. One
+particular cumbersome issue we had to overcome was the emulation of the QEMU
+Object Model. Since QEMU is written in C, it uses its own object model to
+implement inheritance. This object model is used throughout QEMU. We took the
+easy way out and just used a C++ wrapper class that contains all QEMU objects
+that are used in the USB subsystem.
+
+The next step was to develop a USB host device model. This model connects a
+USB device attached to Genode's USB host-controller driver to the xHCI device
+model. Lucky for us, QEMU already contains a USB host device model that uses
+libusb, which we could use as blueprint. We implemented a USB host device that
+leverages Genode's custom USB session interface. This host device reacts to a
+USB device report coming from another component such as the host-controller
+driver. It tries to claim all devices it finds in that report and then creates
+a QEMU USB device for each of them that is attached to the xHCI device model.
+
+The xHCI device model needs infrastructure that normally is provided by QEMU
+itself such as a timer queue and PCI device handling. We introduced a QEMU
+USB controller interface _repos/libports/include/qemu/usb.h_ whose back-end
+library interface has to be implemented by a component, i.e. the VMM, that
+wants to use the library.
+
+In the end, this work resulted in a small library that contains the xHCI
+device model and works in a standalone way. All required resources have to be
+provided by the component using the library. This makes it easy to integrate
+the library in different VMMs because the user of the library is not forced to
+employ the library in a certain way but free to use it any way he chooses.
+
+
+xHCI device model wrapper in VirtualBox
+---------------------------------------
+
+We implemented an xHCI device model _repos/port/src/virtualbox/devxhci.cc_ in
+VirtualBox that merely wraps the QEMU USB library and provides the back-end
+functionality required by the library to glue QEMU's xHCI device model to
+VirtualBox. For now, this device is always part of a VM because there is
+currently no way to disable it from within the VirtualBox configuration
+front end. Therefore, it is necessary to always give VirtualBox access to a
+_usb_devices_ ROM module.
+
+We removed the afore mentioned USB proxy service from our VirtualBox port
+because it became redundant with the advent of our xHCI device model.
+
+
+USB device report filter
+------------------------
+
+With the xHCI support in VirtualBox in place, we had to come up with a
+mechanism to select, which USB devices it may access. Since USB devices are
+usually hot-plugged by the user of the system, we need to be able to configure
+the access permissions dynamically at run-time. On this account, we created a
+component that intercepts the report from the USB host-controller driver. On
+the one hand, this USB device report-filter component screens the device
+report coming from the USB host-controller driver by checking each reported
+device against a given white list of devices. Only approved devices are
+reported to a consumer of the report, i.e. VirtualBox. On the other hand, this
+component generates a new configuration for the USB host-controller driver.
+The configuration has to be changed each time the filter component finds a
+suitable device because the driver will hand out access to a given device to a
+client only if there is a valid policy. As we do not know in advance, which
+devices might be plugged in, this policy must be maintained dynamically. The
+report filter will send the device report only if the host-controller driver
+has changed its configuration. This ensures that a matching policy will be in
+effect at the time when the client component tries to access the device.
+
+The configuration of the report-filter component can also be changed at run
+time.
+
+See _repos/os/src/app/usb_report_filter/README_ for more details on how the
+USB device report filter may be configured.
+
+
+Example configuration
+---------------------
+
+The following figure illustrates the interplay and configuration of the
+involved components:
+
+[image qemu_xhci]
+
+When the user plugs in a USB device, the USB host-controller driver generates
+a device report that is consumed by the USB device report-filter component
+(1). The filter component then examines the report and checks if it contains a
+device it should report to its report consumer. It then reconfigures the
+host-controller driver (2). Afterwards it sends a report to its consumer (3).
+The consumer, in this case a VMM, then accesses the USB device (4).
+
+
+New support for the RISC-V CPU architecture
+###########################################
+
+We became aware of [http://riscv.org - RISC-V] when attending several talks
+about the project at [https://fosdem.org - FOSDEM] in 2015. RISC-V aims to be
+an open-source hardware architecture and is now complemented by many projects
+that target the release of real hardware or ASICs (for example,
+[http://lowrisc.org - the LowRISC project]). We have experience with various
+major CPU architectures and many systems on a chip and, therefore, embrace a
+sharp eye on certain platform properties. Intel's ME and ARM's Trustzone
+practically lock out operating systems of certain hardware and firmware
+features. The true nature of these mechanisms becomes increasingly dubious,
+especially when trying to build a secure open-source operating system. Intel's
+AMT technology for instance comes with a complete TCP/IP stack that intercepts
+packets from the integrated NIC and a VNC server that can magically expose a
+mouse and a keyboard at the USB controller. If you are interested in more
+details about this topic
+[http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf - Intel x86 considered harmful]
+by Joanna Rutkowska is a very good read. We decided to have a deeper look at
+the RISC-V architecture as an alternative open hardware platform. Especially,
+since the LowRISC project promises a completely open system on chip, including
+the peripherals.
+
+RISC-V comes with a lot of optional features, so it can cover a large field of
+applications reaching from simple I/O processors to general-purpose computing.
+For example, there are 64 and 32 bit ISA (instruction set architecture)
+versions, three page table formats with the option to omit paging at all, up
+to four privilege modes, and a minimal integer core ISA (I). Everything else,
+like multiplication and division (M), atomic instructions (A), and floating
+point support (F) are subject to ISA extensions and are completely optional
+for a specific hardware implementation.
+
+For Genode, we chose to add the RISC-V support to our custom _base-hw_ kernel.
+Since Genode may be used as a general purpose OS, we implemented the kernel
+using the 64 bit RISC-V version, the Sv39 three-level page table format, and
+the so-called general-purpose extension (G), which is the abbreviation for the
+IAMF extensions. The current implementation provides the kernel and the
+necessary adaptations of the user level part of core.
+
+For testing, we used the RISC-V instruction emulator called
+[https://github.com/riscv/riscv-isa-sim - Spike]. There also exists a RISC-V
+implementation for various Zynq FPGAs. Genode's Zynq board support has kindly
+been added and contributed by Mark Vels.
+
+In the current state, basic Genode applications including core, init, and
+components that use shared libraries can be executed on top of our RISC-V
+port. We did not enable the libc and postponed further activity as the
+platform currently does not specify the interaction with peripherals.
+
+
+Steps to test Genode on RISC-V
+------------------------------
+
+# Building the instruction emulator
+
+  ! # download the front end server
+  ! git clone https://github.com/ssumpf/riscv-fesvr.git
+  !
+  ! # build the front end server
+  ! cd riscv-fesvr
+  ! mkdir build
+  ! cd build
+  ! export RISCV=<installation path>
+  ! ../configure --prefix=$RISCV
+  ! (sudo) make install
+  !
+  ! # download the instruction emulator
+  ! cd ../../
+  ! git clone https://github.com/ssumpf/riscv-isa-sim.git
+  ! cd riscv-isa-sim
+  !
+  ! # build the emulator
+  ! mkdir build
+  ! cd build
+  ! ../configure --prefix=$RISCV --with-fesvr=$RISCV
+  ! (sudo) make install
+  !
+  ! # add $RISCV/bin to path
+  ! export PATH=$RISCV/bin:$PATH
+
+# Building Genode and running a test scenario
+
+  ! # download Genode
+  ! cd ../../
+  ! git clone https://github.com/genodelabs/genode.git
+  !
+  ! # build the Genode tool chain
+  ! cd genode
+  ! ./tool/tool_chain riscv
+  !
+  ! # create RISC-V build directory
+  ! ./tool/create_builddir hw_riscv
+  ! cd build/hw_riscv
+  !
+  ! # build and execute the printf run script
+  ! make run/printf
+
+
+GUI stack usability improvements
+################################
+
+Motivated by the daily use of Genode as desktop OS by an increasingly number
+of developers, the window-layouter component of the
+[http://genode.org/documentation/release-notes/15.11#GUI_stack - GUI stack]
+received welcomed usability improvements.
+
+
+Configurable window placement
+-----------------------------
+
+The policy of the window layouter can be adjusted via its configuration. For
+a given window label, the window's initial position and its maximized state
+can be defined as follows:
+
+! <config>
+!   <policy label="mupdf" maximized="yes"/>
+!   <policy label="nit_fb" xpos="50" ypos="50"/>
+! </config>
+
+
+Keyboard shortcuts
+------------------
+
+The window layouter has become able to respond to key sequences. However,
+normally, the layouter is not a regular nitpicker client but receives only
+those input events that refer to the window decorations. It never owns the
+keyboard focus. In order to propagate global key sequences to the layouter,
+nitpicker must be explicitly configured to direct key sequences initiated with
+certain keys to the decorator. For example, the following nitpicker
+configuration routes key sequences starting with the left windows key to the
+decorator. The window manager, in turn, forwards those events to the layouter.
+
+! <start name="nitpicker">
+!   ...
+!   <config>
+!     ...
+!     <global-key name="KEY_LEFTMETA" label="wm -> decorator" />
+!     ...
+!   </config>
+!   ...
+! </start>
+
+The response of the window layouter to key sequences can be expressed in the
+layouter configuration as follows:
+
+! <config>
+!   <press key="KEY_LEFTMETA">
+!     <press key="KEY_TAB"              action="next_window">
+!       <release key="KEY_TAB">
+!         <release key="KEY_LEFTMETA"   action="raise_window"/>
+!       </release>
+!     </press>
+!     <press key="KEY_LEFTSHIFT">
+!       <press key="KEY_TAB"            action="prev_window">
+!         <release key="KEY_TAB">
+!           <release key="KEY_LEFTMETA" action="raise_window"/>
+!         </release>
+!       </press>
+!     </press>
+!     <press key="KEY_ENTER"            action="toggle_fullscreen"/>
+!   </press>
+! </config>
+
+Each '<press>' node defines the policy when the specified 'key' is pressed.
+It can be equipped with an 'action' attribute that triggers a window action.
+The supported window actions are:
+
+:next_window:       Focus the next window in the focus history.
+:prev_window:       Focus the previous window in the focus history.
+:raise_window:      Bring the focused window to the front.
+:toggle_fullscreen: Maximize/unmaximize the focused window.
+
+By nesting '<press>' nodes, actions can be tied to key sequences. In the
+example above, the 'next_window' action is executed only if TAB is pressed
+while the left windows-key is kept pressed. Furthermore, key sequences can
+contain specific release events. In the example above, the release of the left
+windows key brings the focused window to front, but only if TAB was pressed
+before.
+
+
+Device drivers
+##############
+
+USB host-controller driver enhancements
+=======================================
+
+The _usb_drv_ component now solely uses a policy to grant other components
+access to USB devices exposed by its raw interface (USB session). On the basis
+of the 'label' attribute, it will choose a pre-configured device that is
+identified by either the 'bus' and 'dev' or the 'vendor' and 'product'
+attribute tuple. To accommodate policy decisions made at run time, the USB
+driver is now able to reload its configuration on demand. The USB device
+report now contains a 'bus' and a 'dev' attribute as well in order to identify
+a USB device more precisely. In addition to that, there is also a generated
+'label' attribute in form of 'usb-<bus>-<dev>' that may be used to form
+policies while configuring the system dynamically, e.g., when using the
+_usb_report_filter_ component.
+
+
+USB mass-storage driver
+=======================
+
+Up to now, access to USB storage devices was provided by the USB
+host-controller driver only. However, its ability to do so is limited. E.g.,
+it only supports one storage device and the storage device cannot be changed
+at run-time. With this release we add a USB mass-storage driver that supports
+UMS bulk-only devices that use the SCSI Block Commands set (direct-access).
+This is still most common for USB sticks. Devices using different command
+sets, e.g SD/HC devices or some external disc drives, will not work properly
+if at all. The driver uses the USB session interface to access the USB device
+and provides its service as block session to its client.
+
+This component is part of the first step providing the ability to mount and
+use USB sticks dynamically when using Genode as a general purpose OS. In the
+future, the _usb_drv_ component should solely be the host-controller driver
+while other tasks are handled by dedicated USB driver components such as this
+one.
+
+
+Audio output on Linux
+=====================
+
+The audio-out driver for Linux was modernized by replacing its multi-threaded
+architecture by an event-driven architecture using Genode's server API. In
+addition, the playback is now driven by a timer. For now it is a periodic
+timer that triggers every 11 ms which is roughly the current audio-out period.
+
+The driver now also behaves like the other BSD-based audio-out driver, i.e.,
+it always advances the play pointer. That is vital for the audio-out stack
+above the driver to work properly (e.g., the mixer).
+
+
+Libraries and applications
+##########################
+
+New Genode-world repository
+===========================
+
+With a growing number of users and contributors comes the desire to bring more
+and more existing software to Genode. Most of such libraries and applications,
+however, are outside of the scope of Genode as an OS framework. In contrast to
+device drivers, protocol stacks, and low-level OS services, which we subject
+to our regular automated tests, most 3rd-party software is pretty independent
+from Genode. The attempt to integrate the growing pool of such diverse
+software into the main repository does not scale.
+
+For this reason, we introduce the new
+[https://github.com/genodelabs/genode-world - Genode World] repository, which
+is the designated place for hosting ported applications, libraries, and games.
+
+To use it, you first need to obtain a clone of Genode:
+
+! git clone https://github.com/genodelabs/genode.git genode
+
+Now, clone the _genode-world.git_ repository to _genode/repos/world:_
+
+! git clone https://github.com/genodelabs/genode-world.git genode/repos/world
+
+By placing the _world_ repository under the _repos/_ directory, Genode's tools
+will automatically incorporate the ports provided by the _world_ repository.
+
+For building software of the _world_ repository, the build-directory
+configuration _etc/build.conf_ must be extended with the following line:
+
+! REPOSITORIES += $(GENODE_DIR)/repos/world
+
+*Word of caution*
+
+In contrast to the components found in the mainline Genode repository, the
+components within the _world_ repository are not subjected to the regular
+quality-assurance measures of Genode Labs. Hence, problems are to be expected.
+If you encounter bugs, build problems, or stability issues, please report them
+to the [https://github.com/genodelabs/genode-world/issues - issue tracker] or
+the [http://genode.org/community/mailing-lists - mailing list].
+
+
+Updated 3rd-party software
+==========================
+
+The following 3rd-party code packages of the _ports_ and _libports_
+repositories have been ported or updated:
+
+* Lynx 2.8.8rel.2 (noux package)
+* OpenSSH 7.1p1 (noux package)
+* tar-1.27 (noux package)
+* libssh 0.7.2
+* Lighttpd 1.4.38
+
+
+Platforms
+#########
+
+Execution on bare hardware (base-hw)
+====================================
+
+Within the last months, the initialization code of our custom kernel got
+re-arranged to simplify the addition of new architectures, e.g., the RISC-V
+port (Section [New support for the RISC-V CPU architecture]) while also making
+its implementation leaner. A positive side effect of this work was the
+generalization of multi-processor and L2-cache support for ARM's Cortex-A9
+CPUs. For instance, the Wandboard (Freescale i.MX6 SoC) is now driven with all
+four cores, and its memory can be accessed with full speed.
+
+Besides those feature additions, we fixed an extremely rare and tricky race
+condition in the implementation of the kernel-protected capabilities,
+introduced in release 15.05. A capability's lifetime within a component is
+tracked by a reference-counting like mechanism that is under control of the
+component itself. When the kernel transfered a capability to a component, and
+the very same capability was deleted within the component simultaneously, the
+received capability was marked as invalid, which led to diverse, sporadic
+faults. This deficit in the capabilities reference-counting is solved with the
+current release.
+
+
+Muen separation kernel
+======================
+
+Build integration
+-----------------
+
+Building Genode scenarios running on top of the
+[http://muen.sk - Muen separation kernel] has been greatly simplified by
+properly integrating the Muen system build process into the Genode build system.
+As described in the
+[http://genode.org/documentation/release-notes/15.08#Genode_on_top_of_the_Muen_Separation_Kernel - 15.08 release notes],
+the architecture with Muen is different since the entire hw_x86_64_muen Genode
+system runs as a guest VM on top of the separation kernel. This means that the
+Genode base-hw image must itself be packaged into the final Muen system image
+as an additional step after the Genode system build.
+
+The packaging process of a Muen system image is performed by the new
+_image/muen_ run-tool plugin, which processes the following RUN_OPT parameters.
+
+:--image-muen-external-build:
+  Muen system is built automatically or externally
+
+:--image-muen-system:
+  Muen system policy
+
+:--image-muen-components:
+  Muen system components required for the given system policy
+
+:--image-muen-hardware:
+  Muen target hardware platform
+
+:--image-muen-gnat-path:
+  Path to GNAT toolchain
+
+:--image-muen-spark-path:
+  Path to SPARK toolchain
+
+The options are automatically added to the _etc/build.conf_ file for the
+hw_x86_64_muen base-hw platform. The
+[http://genode.org/documentation/platforms/muen - documentation] has been
+updated to reflect the new, simplified build process.
+
+A port file was added to facilitate the download of the Muen sources v0.7 and
+to check the required dependencies.
+
+Using the new _image/muen_ script in combination with iPXE allows to run the
+Genode test suite via the autopilot tool.
+
+
+MSI support
+-----------
+
+Muen employs Intel VT-d interrupt remapping (IR) besides DMA remapping for
+secure device assignment. As a consequence, PCI devices using Message Signaled
+Interrupts (MSI) must be programmed to trigger requests in remappable format
+(see Intel VT-d specification, Section 5.1.2.2 for further details).
+
+To enable the use of MSIs with the base-hw kernel, a platform-specific
+function has been introduced that returns the necessary MSI parameters for a
+given PCI device. If either the platform or the specific device does not
+support MSI, the function returns false.
+
+On hw_x86_64_muen, the function consults the Muen subject info page to supply
+the appropriate information to the IRQ session. This allows Genode device
+drivers to transparently use MSIs for passed-through PCI devices.
+
+
+seL4 version 2.1
+================
+
+By the end of 2015, the [http://sel4.systems/ - seL4 kernel] version 2.0 was
+published. With the current release, we update Genode's preliminary support
+for this kernel from the experimental branch of one year ago to the master
+branch of version 2.1. Note that this line of work is still considered as an
+exploration. As of now, there is still a way to go until we can leverage seL4
+as a fully featured base platform. Under the hood of Genode, the transition to
+the version 2.1 master branch had the following implications.
+
+In contrast to the experimental branch, the seL4 master branch has no way to
+manually define the allocation of kernel objects within untyped memory ranges.
+Instead, the kernel maintains a built-in allocation policy. This policy rules
+out the deallocation of once-used parts of untyped memory. The only way to
+reuse memory is to revoke the entire untyped memory range. Consequently, we
+cannot share a large untyped memory range for kernel objects of different
+protection domains. In order to reuse memory at a reasonably fine granularity,
+we need to split the initial untyped memory ranges into small chunks that can
+be individually revoked. Those chunks are called "untyped pages". An untyped
+page is a 4 KiB untyped memory region.
+
+The bootstrapping of core has to employ a two-stage allocation approach now.
+For creating the initial kernel objects for core, which remain static during
+the entire lifetime of the system, kernel objects are created directly out of
+the initial untyped memory regions as reported by the kernel. The so-called
+"initial untyped pool" keeps track of the consumption of those untyped memory
+ranges by mimicking the kernel's internal allocation policy. Kernel objects
+created this way can be of any size. For example the CNode, which is used to
+store page-frame capabilities is 16 MiB in size. Also, core's CSpace uses a
+relatively large CNode.
+
+After the initial setup phase, all remaining untyped memory is turned into
+untyped pages. From this point on, newly created kernel objects cannot exceed
+4 KiB in size because one kernel object cannot span multiple untyped memory
+regions. The capability selectors for untyped pages are organized similarly to
+those of page-frame capabilities. There is a new 2nd-level CNode
+(UNTYPED_CORE_CNODE) that is dimensioned according to the maximum amount of
+physical memory (1M entries, each entry representing 4 KiB). The CNode is
+organized such that an index into the CNode directly corresponds to the
+physical frame number of the underlying memory. This way, we can easily
+determine an untyped page selector for any physical addresses, i.e., for
+revoking the kernel objects allocated at a specific physical page. The
+downside is the need for another 16 MiB chunk of meta data. Also, we need to
+keep in mind that this approach won't scale to 64-bit systems. We will
+eventually need to replace the PHYS_CORE_CNODE and UNTYPED_CORE_CNODE by CNode
+hierarchies to model a sparsely populated CNode. The following figure
+illustrates the layout of core's capability space.
+
+[image sel4_core_cspace_master]
+  Organization of core's capability space on seL4
+
+For each protection domain, core maintains a so-called VM CSpace that holds
+capability selectors for page frames and page tables. The size constraint of
+kernel objects has the immediate implication that the VM CSpaces of protection
+domains must be organized via several levels of CNodes. I.e., as the top-level
+CNode of core has a size of 2^12, the remaining 20 PD-specific CSpace address
+bits are organized as a 2nd-level 2^4 padding CNode, a 3rd-level 2^8 CNode,
+and several 4th-level 2^8 leaf CNodes. The latter contain the actual selectors
+for the page tables and page-table entries of the respective PD.
+
+As another slight difference from the experimental branch, the master branch
+requires the explicit assignment of page directories to an ASID pool.
+
+Functionality-wise the update to version 2.1 brings no changes. The
+preliminary support is still limited to Genode's most fundamental mechanisms
+like the bootstrapping, the creation of protection domains, the execution of
+threads, and inter-component communication. User-level device drivers are not
+supported yet. Such functional improvements are scheduled for Genode 16.08.
+
+
+Linux
+=====
+
+We started to experience crashes of our dynamic linker (ldso) when using
+Genode's _base-linux_ platform on recent Linux kernels. Ldso is primarily a
+shared object, which is linked to dynamic binaries. But ldso is also an
+executable, which, once started loads the dynamically-linked binary along with
+all shared libraries required by the binary. Up to now, ldso had to be loaded
+at a link address defined at compilation time, which we enforced through
+linker-script magic. Unfortunately, this does not work any longer on recent
+Linux versions. The kernel notices that ldso is a shared object and loads it
+at an arbitrary (randomized) address, which ultimately results in a
+segmentation fault during ldso initialization. We found a fix for this issue
+by marking ldso as an executable in the ELF header. But since ldso is linked
+to all dynamic binaries (it contains Genode's base libraries) the GNU linker
+then refused to link because ldso was not marked as a shared object.
+Therefore, we decided to implement true self relocation within ldso. This
+feature only works on Genode's base-linux platform as it requires some
+symbol-address magic.
+

doc/road_map.txt

@@ -14,56 +14,99 @@ The road map is not fixed. If there is commercial interest of pushing the
 Genode technology to a certain direction, we are willing to revisit our plans.
 
 
-Review of 2014
+Review of 2015
 ##############
 
-Most of the progress in 2014 was motivated by our goal to use
-Genode as general-purpose OS on x86-based platforms. To highlight a
-few achievements, we started to use [http://rumpkernel.org/ - Rump kernels]
-as file-system providers, enabled VirtualBox on NOVA, pulled off the
-engineering feat to run the Intel Wireless stack natively on microkernels, and
-came up with a new GUI architecture. We regard these features as the
-groundwork to make Genode a feasible platform for day-to-day computing.
+In the beginning of 2015, we declared four main topics to work on, namely
+Genode as general-purpose OS, our custom base-hw kernel platform, thorough
+documentation, and the seL4 kernel. It goes without saying that the stability
+and performance of the base system is a fundamental requirement for the first
+topic.
 
-That said, even though we are proud about the progress, we are still not there
-yet. So what keeps us back? The answer is actually not technical. Most
-developments over the past years were concerned with individual features or
-technical challenges. But the integration of sophisticated system scenarios
-was a rare occurrence. For the most part, such integration activities were
-solely triggered by a particular project or by a presentation. In order to
-make Genode fit for regular use, we need to make the composing of advanced
-systems a habit for most of the regular developers.
+In mid of 2015, we eventually reached the point where a hand full of
+developers started using Genode as their day-to-day OS in the form of the
+so-called
+[https://github.com/genodelabs/genode/issues/1552 - Turmvilla scenario].
+By the end of the year, the performance, stability, and device-driver support
+had reached a level that leaves people impressed every time we have the chance
+to show off our system. Once people become interested, the Genode Foundations
+book - published in Spring - provides a smooth introduction into Genode. The
+Turmvilla scenario is currently based on the NOVA kernel. For the future, we
+want to use also other kernels, in particular our custom base-hw kernel and
+seL4. Thanks to the contribution of
+[http://codelabs.ch - Codelabs], base-hw became usable on the 64-bit x86
+architecture and on the Muen separation kernel in particular. With our work
+on seL4, we reached the point where basic Genode scenarios are executable
+on this kernel.
+
+After having passed the point where a few enthusiasts are able to use Genode
+as day-to-day OS, we should put the emphasis of 2016 on
+ways to make Genode accessible for a wider community.
 
 
-Big picture for 2015
+Big picture for 2016
 ####################
 
-On the account of this realization, the overall theme of 2015 will be the
-consolidation and cultivation of the existing feature set rather than the
-conquering of new grounds. This implies the following topics:
+We identified two possible ways to extend the Genode community.
 
-* Advancing our automated test and integration infrastructure towards
-  the continuous integration of real-world system scenarios,
-* Fostering good-quality documentation,
-* Optimization of performance and stability,
-* Improvement of our tooling
+By community we refer to two groups of people. The first group are
+maker-minded people with a strong incentive to build things. By publishing a
+series of step-by-step guides that explain how to put Genode components
+together in order to create custom system scenarios, we intend to spark
+interest of system builders in Genode. Those articles could be accompanied by
+screencasts or live-system images.
 
-Furthermore, we have to address outstanding limitations of the most
-commonly used base platforms, namely base-hw and NOVA. I.e., only
-with kernel-protected capabilities, base-hw can be considered as a viable
-base platform for security-critical systems, and only with proper
-kernel-resource management, NOVA can be recommended as a kernel for
-general-purpose computing.
+The second group are certain end users with a strong desire for privacy and
+security. We expect this narrow user group to willingly trade the comfort and
+features of traditional desktop OSes for the benefits of Genode. We plan to
+showcase a system with practical value for this group, for example a
+disposable OS like Tails that allows the user to browse the internet via the
+Tor network.
 
-Besides the cultivation of the existing feature set, there will still be room
-for new things. We are particularly excited about the prospect of combining
-Genode with the [http://sel4.systems - seL4 kernel] and
-the [http://nixos.org/nix/ - Nix package manager]. Furthermore, we desire to
-continue the work on our new GUI architecture towards a capability-based
-desktop environment.
+In this spirit, the leitmotif for 2016 will be: Let us make Genode accessible
+to the world outside the inner circle of us enthusiasts.
+
+On a technical level, this motive implicates the following topics:
+
+* The deployment, management, and configuration of Genode systems, i.e., by
+  bringing forward our work on the Nix package manager and by fostering
+  dynamic configurability. This direction also reinforces the need to achieve
+  binary compatibility between the various base platforms to make the
+  distribution of binary packages, reproducible builds, and continuous test
+  and integration scalable.
+
+* Accommodation of common desktop use cases like plugging in a USB
+  stick to work with the files stored on it. Also disk encryption comes
+  into mind.
+
+* Optimization of Genode for the use on a laptop, e.g., addressing
+  fan control, power management, suspend/resume, and similar features.
+
+* Identifying ways of how Genode could contribute additional value to
+  Xen-based environments like Amazon EC2 and Qubes OS.
+
+* Foster the cross-pollination of the seL4 and Genode communities.
+  Genode would allow the seL4 community to move beyond static system
+  scenarios.
+
+* As most use cases rely on networking, we acknowledge the need for
+  improving Genode's network support such as NAT, the robustness of the
+  available TCP/IP stacks and drivers, encryption, and possibly IPv6.
+
+* Genode as distributed system, e.g., a system spread over multiple FPGA-based
+  softcore CPUs, over multiple domains of the Muen separation kernel, or a
+  local machine and a cloud-service provider.
+
+Assuming that we succeed in drawing the attention of a broader audience
+to our project, we should make sure that Genode's API won't undergo
+major changes soon after this point. Today, there are still a number of
+deficiencies in the current API. We should finalize the renovation of
+the Genode API until the mid of 2016. This will also be right the time for
+updating the Genode book. Also, the planned step-by-step guides will
+be based on the modernized API.
 
 
-Milestones for 2015
+Milestones for 2016
 ###################
 
 In the following, we present a rough schedule of the planned work. As usual,
@@ -71,38 +114,41 @@ it is not set in stone. If you are interested in a particular line of work,
 please get in touch.
 
 
-February - Release 15.02
+February - Release 16.02
 ========================
 
-* ARM virtualization on top of the base-hw kernel
-* Modularized tooling for automated tests
+* RISC-V architecture support
+* seL4 version 2.0
+* Assignment of USB devices to VirtualBox guests
+* API modernization (introduction of new component API, deprecation
+  of API legacies)
 
 
-May - Release 15.05
+May - Release 16.05
 ===================
 
-* Comprehensive documentation of the Genode foundations
-* Kernel-protected capabilities for the base-hw kernel
-* seL4 microkernel as base platform
-* Refined platform-driver architecture (support for MSIs, assignment of
-  I/O resources to drivers, standardized configuration)
+* VirtualBox on top of the Muen separation kernel
+* Update of the Genode Foundations book
+* NAT component
+* API modernization (removal of API legacies)
+* Definition of "packages"
 
 
-August - Release 15.08
+August - Release 16.08
 ======================
 
-* Capability-based desktop environment allowing the interactive installation
-  and management of Genode subsystems and the interaction with files
-* Accommodation of typical desktop-computing tasks (e.g., email)
-* Interactive tools for observing the system behavior
-* NOVA kernel-resource management
+* Cross-kernel binary compatibility
+* Interactive system scenarios on top of seL4
+* Networking via Tor
+* Block encryption
+* Build-system support for handling packages
 
 
-November - Release 15.11
+November - Release 16.11
 ========================
 
-* Achieving cross-kernel binary compatibility
-* Package management
-* Modern web browser
-
+* Genode on top of Xen
+* Exploration of Genode as distributed system
+* Deployment of packages
+* On-target building of packages
 

doc/tool_chain.txt

@@ -14,8 +14,8 @@ Genode.
 Recommended development platform
 ################################
 
-We currently use [http://www.ubuntu.com/ - Ubuntu] 12.04 LTS on servers and
-client machines. Hence, Genode should always build without trouble on these
+We use recent [http://www.ubuntu.com/ - Ubuntu] LTS releases on our
+development hosts. Hence, Genode should always build without trouble on these
 platforms.
 
 
@@ -23,9 +23,10 @@ Unified tool chain
 ##################
 
 Starting with Genode version 11.11, there is a unified tool chain for all base
-platforms and supported CPU architectures (x86_32, x86_64, and ARM). For Genode
-development, we highly recommend the use of the official Genode tool chain. It
-can be obtained in two ways: as pre-compiled binaries or manually compiled:
+platforms and supported CPU architectures (x86_32, x86_64, ARM, and RISC-V). For
+Genode development, we highly recommend the use of the official Genode tool
+chain. It can be obtained in two ways: as pre-compiled binaries or manually
+compiled:
 
 :Pre-compiled:
   Our pre-compiled tool chain is runnable on Linux x86_32 and x86_64. The
@@ -44,12 +45,12 @@ can be obtained in two ways: as pre-compiled binaries or manually compiled:
   instructions, just start the tool without arguments.
 
 In both cases, the tool chain will be installed to '/usr/local/genode-gcc'. All
-tools are prefixed with 'genode-x86-' or 'genode-arm-' respectively such that
-it is safe to add the installation directory to our 'PATH' variable (optional).
-The Genode tool chain will be used by the Genode build system by default. If
-you desire to use a different tool chain, create a file called 'tools.conf' in
-the 'etc/' subdirectory of your build directory where you can define the
-tool-chain prefix to be used:
+tools are prefixed with 'genode-x86-', 'genode-arm-', or 'genode-riscv-'
+respectively such that it is safe to add the installation directory to our
+'PATH' variable (optional). The Genode tool chain will be used by the Genode
+build system by default. If you desire to use a different tool chain, create a
+file called 'tools.conf' in the 'etc/' subdirectory of your build directory
+where you can define the tool-chain prefix to be used:
 
 ! CROSS_DEV_PREFIX = /path/to/your/custom/tool_chain/your-x86-
 
@@ -58,20 +59,6 @@ see a valid reason not to use it, please contact us (e.g., via the mailing
 list).
 
 
-; XXX The Gentoo Portage overlay must be update to the new tool chain
-;
-;Gentoo Portage overlay
-;######################
-;
-;For Gentoo users, there exist a Portage overlay, which includes the Genode
-;toolchain.
-;
-;:[https://github.com/blitz/blitz-overlay]:
-;  Portage overlay for using the Genode tool chain on Gentoo
-;
-;You'll find the toolchain under sys-devel/genode-toolchain.
-
-
 Background information - Why do we need a special tool chain?
 #############################################################
 

repos/README

@@ -10,7 +10,7 @@ build-system manual:
 
 :Build-system manual:
 
-  [http://genode.org/documentation/developer-resources/build_system]
+  [https://genode.org/documentation/developer-resources/build_system]
 
 The build system uses a configurable selection of those reposities to obtain
 the source codes for the build process. The repositories are not independent
@@ -31,40 +31,37 @@ but build upon of each other:
 
   :'nova':
     NOVA hypervisor developed at University of Technology Dresden
-    See [http://genode.org/documentation/platforms/nova]
+    See [https://genode.org/documentation/platforms/nova]
 
   :'foc':
     Fiasco.OC is a modernized version of the Fiasco microkernel with a
     completely revised kernel interface fostering capability-based
     security. It is not compatible with L4/Fiasco.
-    See [http://genode.org/documentation/platforms/foc]
+    See [https://genode.org/documentation/platforms/foc]
 
   :'hw':
-    The hw platform allows the execution of Genode on bare ARM hardware
+    The hw platform allows the execution of Genode on bare ARM and x86 hardware
     without the need for a separate kernel. The kernel functionality is
-    included in core.
-    See [http://genode.org/documentation/platforms/hw]
+    included in core except in the special case of the Muen separation
+    kernel.
+    See [https://genode.org/documentation/platforms/hw] and
+    [https://genode.org/documentation/platforms/muen]
 
   :'okl4':
     OKL4 kernel (x86_32 and ARM) developed at Open-Kernel-Labs.
-    See [http://genode.org/documentation/platforms/okl4]
+    See [https://genode.org/documentation/platforms/okl4]
 
   :'pistachio':
     L4ka::Pistachio kernel developed at University of Karlsruhe.
-    See [http://genode.org/documentation/platforms/pistachio]
+    See [https://genode.org/documentation/platforms/pistachio]
 
   :'fiasco':
     L4/Fiasco kernel developed at University of Technology Dresden.
-    See [http://genode.org/documentation/platforms/fiasco]
+    See [https://genode.org/documentation/platforms/fiasco]
 
-  :'codezero':
-    Codezero microkernel developed by B-Labs
-    See [http://genode.org/documentation/platforms/codezero]
-
-  :'host':
-    Pseudo platform documenting the interface between the generic and
-    platform-specific parts of the base framework. This is not a functional
-    base platform.
+  :'sel4':
+    seL4 microkernel developed at NICTA/General Dynamics
+    See[https://sel4.systems/]
 
 :'os':
 
@@ -102,10 +99,10 @@ but build upon of each other:
   This source-code repository contains the device-driver environment for
   executing drivers of the iPXE project.
 
-:'dde_oss':
+:'dde_bsd':
 
-  This source-code repository contains the device-driver environment for the
-  audio drivers of the Open Sound System (OSS).
+  This source-code repository contains the device-driver environment for
+  drivers of the OpenBSD operating system.
 
 :'dde_rump':
 

repos/base-codezero/Makefile

@@ -1,25 +0,0 @@
-#
-# \brief  Download and prepare the Codezero kernel
-# \author Norman Feske
-# \date   2011-08-05
-#
-
-VERBOSE ?= @
-ECHO    := @echo
-
-#
-# Print help information by default
-#
-help::
-
-prepare:
-	$(VERBOSE)../../tool/ports/prepare_port codezero
-
-help::
-	$(ECHO)
-	$(ECHO) "Prepare the codezero base repository"
-	$(ECHO)
-	$(ECHO) "--- available commands ---"
-	$(ECHO) "prepare - checkout upstream source codes"
-	$(ECHO) "clean   - remove upstream source codes"
-	$(ECHO)

repos/base-codezero/README

@@ -1,3 +0,0 @@
-This repository contains the port of Genode to the Codezero microkernel
-For instructions about using Genode with Codezero, please refer to
-'doc/codezero.txt'.

repos/base-codezero/config/vpb926.cml

@@ -1,240 +0,0 @@
-#
-# Automatically generated, don't edit
-#
-# Generated on: furnace
-# At: Fri, 05 Aug 2011 21:48:00 +0000
-# Linux version 2.6.32-33-generic (buildd@rothera) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #70-Ubuntu SMP Thu Jul 7 21:09:46 UTC 2011
-
-#
-# Codezero Microkernel Configurator
-#
-
-#
-# Main architecture
-#
-CONFIG_ARCH_ARM=y
-
-
-#
-# ARM Architecture Configuration
-#
-
-#
-# ARM Platform Type
-#
-CONFIG_PLATFORM_PB926=y
-CONFIG_PLATFORM_PBA9=n
-CONFIG_PLATFORM_BEAGLE=n
-CONFIG_PLATFORM_EB=n
-
-
-#
-# ARM Processor Type
-#
-CONFIG_CPU_ARM926=y
-
-
-
-#
-# Generic Processor Properties
-#
-CONFIG_ICACHE_DISABLE=n
-CONFIG_DCACHE_DISABLE=n
-
-
-#
-# Generic Kernel Properties
-#
-CONFIG_PREEMPT_DISABLE=n
-CONFIG_DEBUG_ACCOUNTING=n
-CONFIG_DEBUG_SPINLOCKS=n
-CONFIG_SCHED_TICKS=1000
-
-
-#
-# Toolchain Prefix
-#
-CONFIG_TOOLCHAIN_USERSPACE="arm-none-linux-gnueabi-"
-CONFIG_TOOLCHAIN_KERNEL="arm-none-eabi-"
-
-
-#
-# Container Setup
-#
-CONFIG_CAPABILITIES=n
-CONFIG_CONTAINERS=1
-
-#
-# Container 0 Parameters
-#
-
-#
-# Container 0 Type
-#
-CONFIG_CONT0_TYPE_BAREMETAL=y
-CONFIG_CONT0_TYPE_POSIX=n
-CONFIG_CONT0_TYPE_LINUX=n
-
-
-#
-# Container 0 Options
-#
-CONFIG_CONT0_OPT_NAME="empty0"
-
-#
-# Baremetal Project Type
-#
-CONFIG_CONT0_BAREMETAL_PROJ_EMPTY=y
-CONFIG_CONT0_BAREMETAL_PROJ_HELLO_WORLD=n
-CONFIG_CONT0_BAREMETAL_PROJ_THREADS_DEMO=n
-CONFIG_CONT0_BAREMETAL_PROJ_TEST_SUITE=n
-CONFIG_CONT0_BAREMETAL_PROJ_UART_SERVICE=n
-CONFIG_CONT0_BAREMETAL_PROJ_TIMER_SERVICE=n
-CONFIG_CONT0_BAREMETAL_PROJ_KMI_SERVICE=n
-CONFIG_CONT0_BAREMETAL_PROJ_MUTEX_DEMO=n
-CONFIG_CONT0_BAREMETAL_PROJ_IPC_DEMO=n
-
-
-#
-# Container 0 Pager Linker Parameters
-#
-CONFIG_CONT0_PAGER_LMA=0x41000
-CONFIG_CONT0_PAGER_VMA=0x100000
-
-
-#
-# Container 0 Pager Physical Memory Regions (Capabilities)
-#
-CONFIG_CONT0_PAGER_PHYSMEM_REGIONS=1
-CONFIG_CONT0_PAGER_PHYS0_START=0x41000
-CONFIG_CONT0_PAGER_PHYS0_END=0x4000000
-
-
-#
-# Container 0 Pager Virtual Memory Regions (Capabilities)
-#
-CONFIG_CONT0_PAGER_VIRTMEM_REGIONS=1
-CONFIG_CONT0_PAGER_VIRT0_START=0x0
-CONFIG_CONT0_PAGER_VIRT0_END=0x50000000
-
-
-#
-# Container 0 Pager Capabilities
-#
-
-#
-# Container 0 Thread Pool Capability
-#
-CONFIG_CONT0_PAGER_CAP_THREADPOOL_USE=y
-CONFIG_CONT0_PAGER_CAP_THREADPOOL_SIZE=64
-
-
-#
-# Container 0 Space Pool Capability
-#
-CONFIG_CONT0_PAGER_CAP_SPACEPOOL_USE=y
-CONFIG_CONT0_PAGER_CAP_SPACEPOOL_SIZE=64
-
-
-#
-# Container 0 Mutex Pool Capability
-#
-CONFIG_CONT0_PAGER_CAP_MUTEXPOOL_USE=y
-CONFIG_CONT0_PAGER_CAP_MUTEXPOOL_SIZE=100
-
-
-#
-# Container 0 Map Pool Capability
-#
-CONFIG_CONT0_PAGER_CAP_MAPPOOL_USE=y
-CONFIG_CONT0_PAGER_CAP_MAPPOOL_SIZE=800
-
-
-#
-# Container 0 IPC Capability
-#
-CONFIG_CONT0_PAGER_CAP_IPC_USE=y
-CONFIG_CONT0_PAGER_CAP_IPC_TARGET_CURRENT_CONTAINER=y
-CONFIG_CONT0_PAGER_CAP_IPC_TARGET_CURRENT_PAGER_SPACE=n
-CONFIG_CONT0_PAGER_CAP_IPC_TARGET_OTHER_CONTAINER=n
-CONFIG_CONT0_PAGER_CAP_IPC_TARGET_OTHER_PAGER=n
-
-
-#
-# Container 0 IRQ Control Capability
-#
-CONFIG_CONT0_PAGER_CAP_IRQCTRL_USE=y
-
-
-#
-# Container 0 Custom Capability 0 Parameters
-#
-CONFIG_CONT0_PAGER_CAP_CUSTOM0_USE=n
-
-
-#
-# Container 0 Custom Capability 1 Parameters
-#
-CONFIG_CONT0_PAGER_CAP_CUSTOM1_USE=n
-
-
-#
-# Container 0 Custom Capability 2 Parameters
-#
-CONFIG_CONT0_PAGER_CAP_CUSTOM2_USE=n
-
-
-#
-# Container 0 Custom Capability 3 Parameters
-#
-CONFIG_CONT0_PAGER_CAP_CUSTOM3_USE=n
-
-
-
-#
-# Container 0 Global Capabilities
-#
-
-#
-# Container 0 IPC Capability
-#
-CONFIG_CONT0_CAP_IPC_USE=y
-CONFIG_CONT0_CAP_IPC_TARGET_CURRENT_CONTAINER=y
-CONFIG_CONT0_CAP_IPC_TARGET_CURRENT_PAGER_SPACE=n
-CONFIG_CONT0_CAP_IPC_TARGET_OTHER_CONTAINER=n
-CONFIG_CONT0_CAP_IPC_TARGET_OTHER_PAGER=n
-
-
-#
-# Container 0 Mutex Pool Capability
-#
-CONFIG_CONT0_CAP_MUTEXPOOL_USE=y
-CONFIG_CONT0_CAP_MUTEXPOOL_SIZE=100
-
-
-
-
-
-
-#
-# Derived symbols
-#
-CONFIG_CONT3_START_PC_ADDR=0xd0000000
-CONFIG_DEBUG_PERFMON_KERNEL=n
-CONFIG_CONT1_PAGER_LOAD_ADDR=0x1100000
-CONFIG_CONT2_START_PC_ADDR=0xc0000000
-CONFIG_CONT2_PAGER_VIRT_ADDR=0xc0000000
-CONFIG_RAM_BASE_PLAT=0
-CONFIG_CONT2_PAGER_LOAD_ADDR=0x2100000
-CONFIG_CONT1_PAGER_VIRT_ADDR=0xb0000000
-CONFIG_CONT3_PAGER_LOAD_ADDR=0x3100000
-CONFIG_SUBARCH_V5=y
-CONFIG_SUBARCH_V7=n
-CONFIG_SUBARCH_V6=n
-CONFIG_CONT0_PAGER_LOAD_ADDR=0x41000
-CONFIG_CONT0_PAGER_VIRT_ADDR=0x100000
-CONFIG_CONT3_PAGER_VIRT_ADDR=0xd0000000
-CONFIG_CONT0_START_PC_ADDR=0x100000
-CONFIG_CONT1_START_PC_ADDR=0xb0000000
-#
-# That's all, folks!

repos/base-codezero/doc/codezero.txt

@@ -1,274 +0,0 @@
-
-                      ==================================
-                      Genode on the Codezero microkernel
-                      ==================================
-
-
-                               Norman Feske
-
-
-Codezero is a microkernel primarily targeted at ARM-based embedded systems.
-It is developed by the British company B-Labs.
-
-:B-Labs website:
-
-  [http://b-labs.com]
-
-The Codezero kernel was first made publicly available in summer 2009. The
-latest version, documentation, and community resources are available at the
-project website:
-
-:Codezero project website:
-
-  [http://l4dev.org]
-
-As highlighted by the name of the project website, the design of the kernel is
-closely related to the family of L4 microkernels. In short, the kernel provides
-a minimalistic set of functionality for managing address spaces, threads, and
-communication between threads, but leaves complicated policy and device access
-to user-level components.
-
-
-Using Genode with Codezero
-##########################
-
-For using Codezero, please ensure to have Git, SCons, and Python installed as
-these tools are required for downloading and building the kernel. Furthermore,
-you will need to install the tool chain for ARM. For instructions on how to
-download and install the tool chain, please refer to:
-
-:[http://genode.org/download/tool-chain]:
-  Genode tool-chain
-
-To download the Codezero kernel and integrate it with Genode, issue
-
-! make prepare
-
-from the 'base-codezero/' directory. The Codezero kernel is fully supported by
-Genode's run mechanism. Therefore, you can run Genode scenarios using Qemu
-directly from the build directory. For a quick test, let's create a build
-directory for Codezero on the VersatilePB926 platform using Genode's
-'create_builddir' tool:
-
-! <genode-dir>/tool/create_builddir codezero_vpb926 BUILD_DIR=<build_dir>
-
-To execute the graphical Genode demo, change to the new created build directory
-and issue:
-
-! make run/demo
-
-
-Characteristics of the kernel
-#############################
-
-To put Codezero in relation to other L4 kernels, here is a quick summary on the
-most important design aspects as implemented with the version 0.3, and on how
-our port of Genode relates to them:
-
-* In the line of the original L4 interface, the kernel uses global name spaces
-  for kernel objects such as threads and address spaces.
-
-* For the interaction between a user thread and the kernel, the concept of
-  user-level thread-control blocks (UTCB) is used. A UTCB is a small
-  thread-specific region in the thread's virtual address space, which is
-  always mapped. Hence the access to the UTCB can never raise a page fault,
-  which makes it perfect for the kernel to access system-call arguments,
-  in particular IPC payload copied from/to user threads. In contrast to other
-  L4 kernels, the location of UTCBs within the virtual address space is managed
-  by the user land.
-
-  On Genode, core keeps track of the UTCB locations for all user threads.
-  This way, the physical backing store for the UTCB can be properly accounted
-  to the corresponding protection domain.
-
-* The kernel provides three kinds of synchronous inter-process communication
-  (IPC): Short IPC carries payload in CPU registers only. Full IPC copies
-  message payload via the UTCBs of the communicating parties. Extended IPC
-  transfers a variable-sized message from/to arbitrary locations of the
-  sender/receiver address spaces. During an extended IPC, page fault may
-  occur.
-
-  Genode solely relies on extended IPC, leaving the other IPC mechanisms to
-  future optimizations.
-
-* The scheduling of threads is based on hard priorities. Threads with the
-  same priority are executed in a round-robin fashion. The kernel supports
-  time-slice-based preemption.
-
-  Genode does not support Codezero priorities yet.
-
-* The original L4 interface leaves open the question on how to manage
-  and account kernel resources such as the memory used for page tables.
-  Codezero makes the accounting of such resources explicit, enables the
-  user-land to manage them in a responsible way, and prevent kernel-resource
-  denial-of-service problems.
-
-* In contrast to the original L4.v2 and L4.x0 interfaces, the kernel provides
-  no time source in the form of IPC timeouts to the user land. A time source
-  must be provided by a user-space timer driver. Genode employs such a timer
-  services on all platforms so that it is not effected by this limitation.
-
-In several ways, Codezero goes beyond the known L4 interfaces. The most
-noticeable addition is the support for so-called containers. A container is
-similar to a virtual machine. It is an execution environment that holds a set
-of physical resources such as RAM and devices. The number of containers and the
-physical resources assigned to them is static and is to be defined at build
-time. The code executed inside a container can be roughly classified into two
-cases. First, there are static programs that require strong isolation from the
-rest of the system but no classical operating-system infrastructure, for
-example special-purpose telecommunication stacks or cryptographic functionality
-of an embedded device. Second, there a kernel-like workload, which use the L4
-interface to substructure the container into address spaces, for example a
-paravirtualized Linux kernel that uses Codezero address spaces to protect Linux
-processes. Genode runs inside a container and facilitates Codezero's L4
-interface to implement its multi-server architecture.
-
-
-Behind the scenes
-#################
-
-The 'make prepare' mechanism checks out the kernel source code from the
-upstream Git repository to 'base-codezero/contrib'. When building the kernel
-from within a Genode build directory via 'make kernel', this directory won't be
-touched by the Genode build system. Instead, a snapshot of the 'contrib'
-directory is taken to '<build-dir>/kernel/codezero'. This is the place where
-the Codezero configuration and build processes are executed. By working with a
-build-directory-local snapshot, we ensure that the source tree remains
-untouched at all times. After having taken the snapshot, the Codezero kernel is
-configured using a configuration template specific for the hardware platform.
-The configuration comes in the form of a CML file located at
-'base-codezero/config/'. There is one CML file per supported platform named
-'<platform>.cml'. The configured Codezero build directory will reside at
-'<build-dir>/kernel/codezero/build/'. Finally, the Codezero build system is
-invoked to build the kernel.
-
-The two stages of building Codezero
-===================================
-
-The Codezero build system always performs the compilation of the kernel and the
-so-called containers as well as the integration of all these components into a
-final ELF image as one operation. When building just the kernel via 'make
-kernel', the final image will contain the default container0 that comes with
-the Codezero distribution. For integrating Genode into the final image, the
-content of the container0 must be replaced by the Genode binaries followed by
-another execution of 'kernel/codezero/build.py'. Now, the single-image will be
-re-created, including the Genode binaries. When using Genode's run mechanism,
-these steps are automated for you. For reference, please review the Codezero
-run environment at 'base-codezero/run/env'.
-
-By first building the kernel with Codezero's default container ('make kernel')
-and later replacing the container's content with Genode binaries, we
-optimize the work flow for building Genode components. The kernel is compiled
-only once, but the (quick) re-linking of the final image is done every time a
-run script is executed.
-
-In the run environment, you will see that we forcefully remove a file called
-'cinfo.c' from the build-directory-local snapshot of the Codezero source tree.
-This file is generated automatically by the Codezero build system and linked
-against the kernel. It contains the parameters of the containers executed on
-the kernel. Because we change the content of container0 each time when
-executing a run script, those parameter change. So we have to enforce to
-re-generation of the 'cinfo.c' file.
-
-How Genode ROM modules are passed into the final image
-======================================================
-
-The Codezero build system picks up any ELF files residing the container's
-directory wheres the file called 'main.elf' is considered to be the roottask
-(in Codezero speak called pager) of the container. For Genode, 'main.elf'
-corresponds to the core executable. All other boot modules are merged into an
-ELF file, which we merely use as a container for these binary data. This ELF
-file is linked such that it gets loaded directly after the core image (this is
-how core finds the boot modules). The process of archiving all boot modules
-into the single ELF file is automated via the 'base-codezero/tool/gen_romfs'
-tool. In the container's directory, the merged file is called 'modules.elf'.
-
-Adapting the source code of the kernel
-======================================
-
-For debugging and development you might desire to change the kernel code
-at times. You can safely do so within the 'base-codezero/contrib/' directory.
-When issuing the next 'make kernel' from the Genode build directory, your
-changes will be picked up. However, when working with run scripts, the kernel
-is not revisited each time. The kernel gets built only once if the
-'<build-dir>/kernel' directory does not exist, yet. If you work on the kernel
-source tree and wish to conveniently test the kernel with a run script, use
-
-! make kernel run/<run-script>
-
-This way, you make sure to rebuild the kernel prior executing the steps
-described in the run script.
-
-Tweaking the kernel configuration
-=================================
-
-The kernel configuration can be tweaked within '<build-dir>/kernel/codezero'.
-Just change to this directory and issue './build.py -C'. The next time you
-build the kernel via 'make kernel' your configuration will be applied.
-If you want to conserve your custom configuration, just copy the file
-'<build-dir>/kernel/codezero/build/config.cml'.
-
-Parameters of 'vpb926.cml' explained
-====================================
-
-The default configuration for the VersatilePB926 platform as found at
-'base-codzero/config/vpb926.cml' is paramaterized as follows:
-
-:Default pager parameters:
-! 0x41000  Pager LMA
-! 0x100000 Pager VMA
-These values are important because they are currently hard-wired in the
-linker script used by Genode. If you need to adopt these values, make
-sure to also update the Genode linker script located at
-'base-codezero/src/platform/genode.ld'.
-
-:Physical Memory Regions:
-! 1         Number of Physical Regions
-! 0x41000   Physical Region 0 Start Address
-! 0x4000000 Physical Region 0 End Address
-We only use 64MB of memory. The physical memory between 0 and 0x41000 is
-used by the kernel.
-
-:Virtual Memory Regions:
-! 1          Number of Virtual Regions
-! 0x0        Virtual Region 0 Start Address
-! 0x50000000 Virtual Region 0 End Address
-It is important to choose the end address such that the virtual memory
-covers the thread context area. The context area is defined at
-'base/include/base/thread.h'.
-
-
-Limitations
-###########
-
-At the current stage, the Genode version for Codezero is primarily geared
-towards the developers of Codezero as a workload to stress their kernel. It
-still has a number of limitations that would affect the real-world use:
-
-* Because the only platform supported out of the box by the official Codezero
-  source tree is the ARM-based Versatilebp board, Genode is currently tied to
-  this hardware platform.
-
-* The current timer driver at 'os/src/drivers/timer/codezero/' is a dummy
-  driver that just yields the CPU time instead of blocking. Is is not
-  suitable as time source.
-
-* The PL110 framebuffer driver at 'os/src/drivers/framebuffer/pl110/'
-  does only support the LCD display as provided by Qemu but it is not tested on
-  real hardware.
-
-* Even though Codezero provides priority-based scheduling, Genode does not
-  allow assigning priorities to Codezero processes, yet.
-
-As always, these limitations will be addressed as needed.
-
-
-Thanks
-######
-
-We want to thank the main developer of Codezero Bahadir Balban for his great
-responsiveness to our feature requests and questions. Without his help, the
-porting effort would have taken much more effort. We hope that our framework
-will be of value to the Codezero community.
-
-

repos/base-codezero/etc/specs.conf

@@ -1 +0,0 @@
-SPECS = genode

repos/base-codezero/include/arm/cpu/atomic.h

@@ -1,33 +0,0 @@
-/*
- * \brief  Atomic operations for ARM on codezero
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _INCLUDE__ARM__CPU__ATOMIC_H_
-#define _INCLUDE__ARM__CPU__ATOMIC_H_
-
-namespace Genode {
-
-	/**
-	 * Atomic compare and exchange
-	 *
-	 * This function compares the value at dest with cmp_val.
-	 * If both values are equal, dest is set to new_val. If
-	 * both values are different, the value at dest remains
-	 * unchanged.
-	 *
-	 * \return  1 if the value was successfully changed to new_val,
-	 *          0 if cmp_val and the value at dest differ.
-	 */
-	int cmpxchg(volatile int *dest, int cmp_val, int new_val);
-}
-
-#endif /* _INCLUDE__ARM__CPU__ATOMIC_H_ */

repos/base-codezero/include/base/ipc_msgbuf.h

@@ -1,63 +0,0 @@
-/*
- * \brief  IPC message buffer
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _INCLUDE__BASE__IPC_MSGBUF_H_
-#define _INCLUDE__BASE__IPC_MSGBUF_H_
-
-namespace Genode {
-
-	/**
-	 * IPC message buffer layout
-	 */
-	class Msgbuf_base
-	{
-		protected:
-
-			size_t _size;
-			char   _msg_start[];  /* symbol marks start of message */
-
-		public:
-
-			/*
-			 * Begin of actual message buffer
-			 */
-			char buf[];
-
-			/**
-			 * Return size of message buffer
-			 */
-			inline size_t size() const { return _size; };
-
-			/**
-			 * Return address of message buffer
-			 */
-			inline void *addr() { return &_msg_start[0]; };
-
-	} __attribute__((aligned(4)));
-
-	/**
-	 * Instance of IPC message buffer with specified buffer size
-	 */
-	template <unsigned BUF_SIZE>
-	class Msgbuf : public Msgbuf_base
-	{
-		public:
-
-			char buf[BUF_SIZE];
-
-			Msgbuf() { _size = BUF_SIZE; }
-
-	} __attribute__((aligned(4)));
-}
-
-#endif /* _INCLUDE__BASE__IPC_MSGBUF_H_ */

repos/base-codezero/include/base/ipc_pager.h

@@ -1,171 +0,0 @@
-/*
- * \brief  Dummy pager support for Genode
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _INCLUDE__BASE__IPC_PAGER_H_
-#define _INCLUDE__BASE__IPC_PAGER_H_
-
-#include <base/cache.h>
-#include <base/ipc.h>
-#include <base/stdint.h>
-#include <base/native_types.h>
-
-namespace Genode {
-
-	class Mapping
-	{
-		private:
-
-			addr_t _from_phys_addr;
-			addr_t _to_virt_addr;
-			size_t _num_pages;
-			bool   _writeable;
-
-			enum { PAGE_SIZE_LOG2 = 12 };
-
-		public:
-
-			/**
-			 * Constructor
-			 */
-			Mapping(addr_t dst_addr, addr_t src_addr,
-			        Cache_attribute const cacheability, bool io_mem,
-			        unsigned l2size = PAGE_SIZE_LOG2,
-			        bool rw = true)
-			:
-				_from_phys_addr(src_addr),
-				_to_virt_addr(dst_addr),
-				_num_pages(1 << (l2size - PAGE_SIZE_LOG2)),
-				_writeable(rw)
-			{ }
-
-			/**
-			 * Construct invalid mapping
-			 */
-			Mapping() : _num_pages(0) { }
-
-			/**
-			 * Prepare map operation
-			 *
-			 * No preparations are needed on Codezero because all mapping
-			 * originate from the physical address space.
-			 */
-			void prepare_map_operation() { }
-
-			addr_t from_phys() const { return _from_phys_addr; }
-			addr_t to_virt()   const { return _to_virt_addr; }
-			size_t num_pages() const { return _num_pages; }
-			bool   writeable() const { return _writeable; }
-	};
-
-
-	/**
-	 * Special paging server class
-	 */
-	class Ipc_pager : public Native_capability
-	{
-		private:
-
-			Native_thread_id _last;      /* faulted thread                 */
-			addr_t           _pf_addr;   /* page-fault address             */
-			addr_t           _pf_ip;     /* instruction pointer of faulter */
-			bool             _pf_write;  /* true on write fault            */
-
-			Mapping _reply_mapping;
-
-//		protected:
-//
-//			/**
-//			 * Wait for pagefault
-//			 */
-//			void _wait();
-//
-//			/**
-//			 * Send page-fault reply and wait for next page fault
-//			 */
-//			void _reply_and_wait();
-
-		public:
-
-			/**
-			 * Constructor
-			 */
-			Ipc_pager();
-
-			/**
-			 * Wait for a new page fault received as short message IPC
-			 */
-			void wait_for_fault();
-
-			/**
-			 * Reply current page-fault and wait for a new one
-			 */
-			void reply_and_wait_for_fault();
-
-			/**
-			 * Request instruction pointer of current page fault
-			 */
-			addr_t fault_ip() { return _pf_ip; }
-
-			/**
-			 * Request fault address of current page fault
-			 */
-			addr_t fault_addr() { return _pf_addr; }
-
-			/**
-			 * Set parameters for next reply
-			 */
-			void set_reply_mapping(Mapping m) { _reply_mapping = m; }
-
-			/**
-			 * Set destination for next reply
-			 */
-			void set_reply_dst(Native_capability pager_object) {
-				_last = pager_object.local_name(); }
-
-			/**
-			 * Answer call without sending a mapping
-			 *
-			 * This function is used to acknowledge local calls from one of
-			 * core's region-manager sessions.
-			 */
-			void acknowledge_wakeup();
-
-			/**
-			 * Return thread ID of last faulter
-			 */
-			Native_thread_id last() const { return _last; }
-
-			/**
-			 * Return badge for faulting thread
-			 */
-			unsigned long badge() const { return _last; }
-
-			/**
-			 * Return true if page fault was a write fault
-			 */
-			bool is_write_fault() const { return _pf_write; }
-
-			/**
-			 * Return true if last fault was an exception
-			 */
-			bool is_exception() const
-			{
-				/*
-				 * Reflection of exceptions is not supported on this platform.
-				 */
-				return false;
-			}
-	};
-}
-
-#endif /* _INCLUDE__BASE__IPC_PAGER_H_ */

repos/base-codezero/include/base/native_types.h

@@ -1,113 +0,0 @@
-/*
- * \brief  Dummy definitions for native types used for compiling unit tests
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _INCLUDE__BASE__NATIVE_TYPES_H_
-#define _INCLUDE__BASE__NATIVE_TYPES_H_
-
-#include <base/native_capability.h>
-#include <base/stdint.h>
-
-namespace Codezero {
-
-	struct l4_mutex;
-
-	enum { NILTHREAD = -1 };
-}
-
-namespace Genode {
-
-	class Platform_thread;
-
-	struct Cap_dst_policy
-	{
-		typedef int Dst;
-
-		static bool valid(Dst tid) { return tid != Codezero::NILTHREAD; }
-		static Dst  invalid()      { return Codezero::NILTHREAD;        }
-		static void copy(void* dst, Native_capability_tpl<Cap_dst_policy>* src);
-	};
-
-	typedef Cap_dst_policy::Dst Native_thread_id;
-
-	struct Native_thread
-	{
-		Native_thread_id l4id;
-
-		/**
-		 * Only used in core
-		 *
-		 * For 'Thread' objects created within core, 'pt' points to the
-		 * physical thread object, which is going to be destroyed on
-		 * destruction of the 'Thread'.
-		 */
-		Platform_thread *pt;
-	};
-
-	/**
-	 * Empty UTCB type expected by the thread library
-	 *
-	 * On this kernel, UTCBs are not placed within the the context area. Each
-	 * thread can request its own UTCB pointer using the kernel interface.
-	 * However, we use the 'Native_utcb' member of the thread context to
-	 * hold thread-specific data, i.e. the running lock used by the lock
-	 * implementation.
-	 */
-	struct Native_utcb
-	{
-		private:
-
-			/**
-			 * Prevent construction
-			 *
-			 * A UTCB is never constructed, it is backed by zero-initialized memory.
-			 */
-			Native_utcb();
-
-			/**
-			 * Backing store for per-thread running lock
-			 *
-			 * The size of this member must equal 'sizeof(Codezero::l4_mutex)'.
-			 * Unfortunately, we cannot include the Codezero headers here.
-			 */
-			int _running_lock;
-
-		public:
-
-			Codezero::l4_mutex *running_lock() {
-				return (Codezero::l4_mutex *)&_running_lock; }
-	};
-
-	typedef Native_capability_tpl<Cap_dst_policy> Native_capability;
-	typedef int Native_connection_state;
-
-	struct Native_config
-	{
-		/**
-		 * Thread-context area configuration.
-		 */
-		static constexpr addr_t context_area_virtual_base() {
-			return 0x40000000UL; }
-		static constexpr addr_t context_area_virtual_size() {
-			return 0x10000000UL; }
-
-		/**
-		 * Size of virtual address region holding the context of one thread
-		 */
-		static constexpr addr_t context_virtual_size() { return 0x00100000UL; }
-	};
-
-	struct Native_pd_args { };
-}
-
-
-#endif /* _INCLUDE__BASE__NATIVE_TYPES_H_ */

repos/base-codezero/include/codezero/syscalls.h

@@ -1,85 +0,0 @@
-/*
- * \brief  Aggregate Codezero syscall bindings
- * \author Norman Feske
- * \date   2010-02-16
- */
-
-/*
- * Copyright (C) 2010-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _INCLUDE__CODEZERO__SYSCALLS_H_
-#define _INCLUDE__CODEZERO__SYSCALLS_H_
-
-/*
- * Codezero headers happen to include the compiler's 'stdarg.h'. If this
- * happened within the 'Codezero' namespace below, we would not be able to
- * include 'stdarg.h' later on into the root namespace (stdarg's include guards
- * would prevent this. Therefore, we make sure to include the file into the
- * root namespace prior processing any Codezero headers.
- */
-#include <stdarg.h>
-
-namespace Codezero { extern "C" {
-
-/* make Codezero includes happy */
-extern char *strncpy(char *dest, const char *src, __SIZE_TYPE__);
-extern void *memcpy(void *dest, const void *src, __SIZE_TYPE__);
-
-/*
- * Work around the problem of C++ keywords being used as
- * argument names in the Codezero API headers.
- */
-#define new _new_
-#define virtual _virtual_
-#define printf(A, ...)
-
-#include <l4lib/macros.h>
-#include <l4lib/arch/arm/syscalls.h>
-#include <l4lib/arch/arm/syslib.h>
-#include <l4lib/ipcdefs.h>
-#include <l4lib/init.h>
-#include <l4lib/mutex.h>
-#include <l4/api/thread.h>
-#include <l4/api/irq.h>
-#include <l4lib/exregs.h>
-#include <l4/lib/list.h>  /* needed for capability.h */
-#include <l4/generic/capability.h>
-#include <l4/generic/cap-types.h>
-#include <l4/arch/arm/exception.h>
-#include <l4/arch/arm/io.h>
-
-#undef new
-#undef virtual
-#ifdef max
-#undef max
-#endif
-#undef printf
-
-/*
- * Turn '#define cacheable' (as defined in the codezero headers) into an enum
- * value. Otherwise, the define will conflict with variables named 'cacheable'.
- */
-enum { _codezero_cacheable = cacheable /* #define value */ };
-#undef cacheable
-enum { cacheable = _codezero_cacheable };
-
-} }
-
-namespace Codezero {
-
-	/**
-	 * Return thread ID of the calling thread
-	 */
-	inline int thread_myself()
-	{
-		struct task_ids ids = { 0, 0, 0 };
-		l4_getid(&ids);
-		return ids.tid;
-	}
-}
-
-#endif /* _INCLUDE__CODEZERO__SYSCALLS_H_ */

repos/base-codezero/lib/import/import-syscall.mk

@@ -1 +0,0 @@
-REP_INC_DIR += include/codezero/dummies

repos/base-codezero/lib/mk/arm_v5/l4_arm_v5.mk

@@ -1,11 +0,0 @@
-CODEZERO_DIR := $(call select_from_ports,codezero)/src/kernel/codezero
-
-LIBL4_DIR = $(CODEZERO_DIR)/conts/userlibs/libl4
-
-INC_DIR += $(CODEZERO_DIR)/conts/userlibs/libc/include
-
-SRC_C += $(notdir $(wildcard $(LIBL4_DIR)/src/arch/arm/v5/*.c))
-SRC_S += $(notdir $(wildcard $(LIBL4_DIR)/src/arch/arm/v5/*.S))
-
-vpath %.c $(LIBL4_DIR)/src/arch/arm/v5
-vpath %.S $(LIBL4_DIR)/src/arch/arm/v5

repos/base-codezero/lib/mk/arm_v5/syscall.mk

@@ -1,3 +0,0 @@
-LIBS += l4_arm_v5
-
-include $(REP_DIR)/lib/mk/l4.inc

repos/base-codezero/lib/mk/base-common.mk

@@ -1,34 +0,0 @@
-#
-# \brief  Portions of base library shared by core and non-core processes
-# \author Norman Feske
-# \date   2013-02-14
-#
-
-LIBS += cxx syscall startup
-
-SRC_CC += cap_copy.cc
-SRC_CC += ipc/ipc.cc ipc/pager.cc ipc/ipc_marshal_cap.cc
-SRC_CC += pager/pager.cc pager/common.cc
-SRC_CC += avl_tree/avl_tree.cc
-SRC_CC += allocator/slab.cc
-SRC_CC += allocator/allocator_avl.cc
-SRC_CC += heap/heap.cc heap/sliced_heap.cc
-SRC_CC += console/console.cc
-SRC_CC += child/child.cc
-SRC_CC += process/process.cc
-SRC_CC += elf/elf_binary.cc
-SRC_CC += lock/lock.cc
-SRC_CC += signal/signal.cc signal/common.cc signal/platform.cc
-SRC_CC += server/server.cc server/common.cc
-SRC_CC += thread/thread.cc thread/myself.cc thread/thread_bootstrap.cc thread/trace.cc
-SRC_CC += thread/context_allocator.cc env/utcb.cc
-SRC_CC += lock/cmpxchg.cc
-
-INC_DIR +=  $(REP_DIR)/src/base/lock
-INC_DIR += $(BASE_DIR)/src/base/lock
-INC_DIR += $(BASE_DIR)/src/base/thread
-INC_DIR +=  $(REP_DIR)/include/codezero/dummies
-
-vpath cap_copy.cc $(BASE_DIR)/src/platform
-vpath %.cc        $(REP_DIR)/src/base
-vpath %.cc        $(BASE_DIR)/src/base

repos/base-codezero/lib/mk/base.mk

@@ -1,14 +0,0 @@
-SRC_CC += console/log_console.cc
-SRC_CC += cpu/cache.cc
-SRC_CC += env/env.cc env/context_area.cc env/reinitialize.cc
-SRC_CC += thread/thread_start.cc
-SRC_CC += irq/platform.cc
-
-INC_DIR += $(BASE_DIR)/src/base/env
-INC_DIR += $(REP_DIR)/include/codezero/dummies
-
-LIBS += base-common
-
-vpath %.cc  $(REP_DIR)/src/base
-vpath %.cc $(BASE_DIR)/src/base
-

repos/base-codezero/lib/mk/codezero_cml.inc

@@ -1,3 +0,0 @@
-ifeq ($(filter-out $(SPECS),platform_vpb926),)
-CODEZERO_CML = $(REP_DIR)/config/vpb926.cml
-endif

repos/base-codezero/lib/mk/l4.inc

@@ -1,51 +0,0 @@
-CODEZERO_DIR := $(call select_from_ports,codezero)/src/kernel/codezero
-
-LIBL4_DIR = $(CODEZERO_DIR)/conts/userlibs/libl4
-
-SRC_C += init.c irq.c mutex.c
-SRC_C += arch/arm/exregs.c
-SRC_S += $(addprefix arch/arm/,syscalls.S new_thread.S)
-SRC_C += $(addprefix lib/,addr.c bit.c idpool.c)
-SRC_C += $(addprefix lib/thread/,init.c thread.c)
-SRC_C += $(addprefix lib/cap/,cap.c read.c)
-
-#
-# Dummies
-#
-SRC_C += dummy.c
-
-INC_DIR += $(CODEZERO_DIR)/conts/userlibs/libc/include
-INC_DIR += $(CODEZERO_DIR)/conts/userlibs/libmem/include
-INC_DIR += $(CODEZERO_DIR)/conts/userlibs/libmem
-
-vpath %   $(LIBL4_DIR)/src
-vpath %.c $(REP_DIR)/src/lib/syscall
-
-#
-# The libl4 source files uses macros defined in macros.h but do not
-# explicitly include the 'macros.h' header file.
-#
-CC_OPT += -include $(LIBL4_DIR)/include/l4lib/macros.h
-
-#
-# Resolve conflicts with built-in functions
-#
-CC_OPT += -fno-builtin-pow
-
-#
-# During the compilation of the libl4 file 'thread.c', the 'l4id_t' type
-# is used without prior inclusion of 'types.h'. Furthermore, 'types.h'
-# has a wrong include guard, so we take care of this problem using a
-# wrapper.
-#
-CC_OPT_lib_thread_thread += -include fix_include_types.h
-CC_OPT_arch_arm_exregs   += -include fix_include_types.h
-
-lib/thread/thread.o arch/arm/exregs.o: fix_include_types.h
-
-fix_include_types.h:
-	@echo "#include <l4lib/arch/arm/types.h>" > $@
-	@echo "#define __L4LIB_ARM_TYPES_H___" >> $@
-
-CC_OPT += -std=gnu99
-

repos/base-codezero/lib/mk/pl011/core_printf.mk

@@ -1,5 +0,0 @@
-SRC_CC   = core_printf.cc
-INC_DIR += $(REP_DIR)/src/base/console/pl011
-INC_DIR += $(REP_DIR)/include/codezero/dummies
-
-vpath core_printf.cc $(BASE_DIR)/src/base/console

repos/base-codezero/lib/mk/platform.mk

@@ -1,33 +0,0 @@
-#
-# Create prerequisites for building Genode for Codezero
-#
-
-#
-# Execute the rules in this file only at the second build stage when we know
-# about the complete build settings, e.g., the 'CROSS_DEV_PREFIX'.
-#
-ifeq ($(called_from_lib_mk),yes)
-
-include $(REP_DIR)/lib/mk/codezero_cml.inc
-
-all: $(BUILD_BASE_DIR)/include/l4/config.h
-
-$(BUILD_BASE_DIR)/include/l4/config.h: $(CODEZERO_CML)
-	$(VERBOSE)mkdir -p $(dir $@)
-	$(VERBOSE)$(CODEZERO_DIR)/tools/cml2header.py -i $^ -o $@
-
-#
-# Codezero's 'macros.h' includes the file "config.h", expected to be located in
-# the same directory (using #include "config.h"). However, 'config.h' is
-# generated into the source tree by the Codezero configuration system. Since we
-# do not want to pollute the source tree, we create a shadow copy of 'macros.h'
-# in the same directory as our generated 'config.h'.
-#
-all: $(BUILD_BASE_DIR)/include/l4/macros.h
-
-$(BUILD_BASE_DIR)/include/l4/macros.h: $(CODEZERO_DIR)/include/l4/macros.h
-	$(VERBOSE)mkdir -p $(dir $@)
-	$(VERBOSE)ln -s $^ $@
-
-endif
-

repos/base-codezero/lib/mk/startup.mk

@@ -1,5 +0,0 @@
-include $(BASE_DIR)/lib/mk/startup.inc
-
-INC_DIR += $(REP_DIR)/include/codezero/dummies
-
-vpath crt0.s $(BASE_DIR)/src/platform/arm

repos/base-codezero/mk/spec-codezero.mk

@@ -1,39 +0,0 @@
-#
-# Specifics for the Codezero kernel API
-#
-
-CODEZERO_DIR := $(call select_from_ports,codezero)/src/kernel/codezero
-
-#
-# Convert path to absolute directory
-#
-absdir = $(shell readlink -f $(1))
-
-#
-# Headers generated within the build directory
-# (see 'lib/mk/platform.mk')
-#
-INC_DIR += $(BUILD_BASE_DIR)/include
-
-#
-# Codezero headers
-#
-INC_DIR += $(CODEZERO_DIR)/include
-INC_DIR += $(CODEZERO_DIR)/conts/userlibs/libl4/include
-INC_DIR += $(CODEZERO_DIR)/conts/userlibs/libdev/uart/include
-
-#
-# Allow programs to test for the Codezero kernel
-#
-# This is needed by the 'pl050/irq_handler.h' to handle the interrupt semantics
-# of Codezero.
-#
-CC_OPT += -D__CODEZERO__
-
-#
-# Clean rules for removing the side effects of building the platform
-#
-clean_includes:
-	$(VERBOSE)rm -rf $(BUILD_BASE_DIR)/include
-
-cleanall: clean_includes

repos/base-codezero/mk/spec-codezero_arm.mk

@@ -1,13 +0,0 @@
-#
-# Specifics for Codezero on ARM
-#
-SPECS += codezero
-
-#
-# Linker options specific for ARM
-#
-LD_TEXT_ADDR ?= 0x02000000
-
-CC_OPT += -D__ARCH__=arm
-
-include $(call select_from_repositories,mk/spec-codezero.mk)

repos/base-codezero/mk/spec-codezero_arm_v5.mk

@@ -1,9 +0,0 @@
-#
-# Specifics for Codezero on ARMv5
-#
-
-SPECS += codezero_arm
-
-CC_OPT += -D__SUBARCH__=v5
-
-include $(call select_from_repositories,mk/spec-codezero_arm.mk)

repos/base-codezero/mk/spec-codezero_platform_vpb926.mk

@@ -1,6 +0,0 @@
-SPECS += codezero_arm_v5 platform_vpb926
-
-CC_OPT += -D__PLATFORM__=pb926
-
-include $(call select_from_repositories,mk/spec-codezero_arm_v5.mk)
-include $(call select_from_repositories,mk/spec-platform_vpb926.mk)

repos/base-codezero/patches/README

@@ -1,67 +0,0 @@
-This directory contains patches of the Codezero kernel that are needed for the
-integration with Genode. Furthermore, some patches address issues with recent
-tool chains not yet supported by the official Codezero verison.
-
-:binutils-2.21.patch:
-
-  The GNU assembler of binutils-2.21 complains with an error that was ignored
-  by previous binutils versions:
-
-  "Error: .size expression for ... does not evaluate to a constant"
-
-  This error seems to occur if the argument of 'BEGIN_PROC' does not match
-  the argument of 'END_PROC'. The patch fixes such inconsistencies in the
-  code.
-
-:gcc_shared_enabled.patch:
-
-  Codezero expect the tool chain to be used for the kernel to not support
-  shared libraries. This is the case for Codesourcery's arm-non-eabi
-  tool chain. Such tool chains use to incorporate both libgcc and libgcc_eh
-  into the single libgcc.a library. In contrast, for tool chains built with
-  '--enable-shared', libgcc does not contain the functions of libgcc_eh. Hence,
-  one symbol called '__aeabi_unwind_cpp_pr0' referenced by libgcc and normally
-  provided by libgcc_eh remains unresolved. There are two possible solutions
-  for this problem: We could link libgcc_eh to the 'final.elf' image as
-  expected by libgcc. However, this way, we will need to implement the
-  the environment expected by libgcc_eh. For Codezero, this is pointless
-  because no C++ is used. The second option is to provide a dummy symbol
-  for '__aeabi_unwind_cpp_pr0' just to make the linker happy. This patch
-  adds such a dummy symbol to 'loader/main.c'.
-
-:libc_search_dir.patch:
-
-  The userlibs are build with w/o '-nostdinc'. Consequently, the standard
-  search paths of the tool chain are used. Because the user land is
-  normally build with the Codesourcery tool chain 'arm-none-linux-gnueabi',
-  the complete glibc headers (that come with the tool chain) end up in
-  the default search path. Coincidentally, the userlibs SConstruct file
-  misses to supply the Codezero libc headers, which goes undetected because
-  headers such as 'stdio.h' are silently taken from the tool chain's libc.
-  This patch supplies Codezero's libc include-search path for building
-  the userlibs. This enables the userlibs to be built with tool chains
-  that do not come with a complete libc.
-
-:scons-2.0.1.patch:
-
-  SCons 2.0.1 complains about the 'build_dir' argument being renamed to
-  'variant_dir'. This patch renames the argument where needed for building
-  the kernel and the default container.
-
-:set_fixed_pager.patch:
-
-  At some point, Codezero abandoned the facility to define the pager for a
-  given thread via the exregs system call. Instead, the kernel hard-wires the
-  creator of the thread as the thread's pager. This is conflicting with
-  Genode's way of creating and paging threads. On the current version of Genode
-  for Codezero, all threads are paged by one thread (thread 3 happens to be the
-  global pager) within core. As a work-around to Codezero's current limitation,
-  we define thread 3 to be the pager of all threads.
-
-:gcc_4_6_1_fixes.patch:
-
-  Version 4.6.1 of GCC is more picky about dead code than previous versions and
-  warns about unused variables. Because Codezero is build with the '-Werror'
-  flag, these warnings cause the kernel build to fail. The patch fixes those
-  warnings by removing the variables in question.
-

repos/base-codezero/patches/binutils-2.21.patch

@@ -1,27 +0,0 @@
---- src/kernel/codezero/src/arch/arm/vectors.S
-+++ src/kernel/codezero/src/arch/arm/vectors.S
-@@ -503,7 +503,7 @@ BEGIN_PROC(arm_irq_exception_basic)
- 	mov	lr, pc
- 	ldr	pc, =do_irq
- 	ldmfd	sp!, {r0-r3, pc}^
--END_PROC(arm_irq_exception)
-+END_PROC(arm_irq_exception_basic)
- 
- /* Minimal IRQ state saved on irq stack right after irq vector enters: */
- #define	IRQ_R0		0
---- src/kernel/codezero/conts/userlibs/libc/src/arch-arm/memcpy.S
-+++ src/kernel/codezero/conts/userlibs/libc/src/arch-arm/memcpy.S
-@@ -57,4 +57,4 @@ BEGIN_PROC(memcpy)
- 		bne last
- 	1:
- 	pop {r0, r4 - r11, pc}
--END_PROC(_memcpy)
-+END_PROC(memcpy)
---- src/kernel/codezero/conts/userlibs/libc/src/arch-arm/memset.S
-+++ src/kernel/codezero/conts/userlibs/libc/src/arch-arm/memset.S
-@@ -65,4 +65,4 @@ BEGIN_PROC(memset)
- 		bne	end
- 
- 	ldmfd	sp!, {r4 - r11, pc}
--END_PROC(_memset)
-+END_PROC(memset)

repos/base-codezero/patches/gcc_4_6_1_fixes.patch

@@ -1,166 +0,0 @@
---- src/kernel/codezero/src/api/map.c
-+++ src/kernel/codezero/src/api/map.c
-@@ -78,6 +78,6 @@ int sys_unmap(unsigned long virtual, unsigned long npages, unsigned int tid)
- 			retval = ret;
- 	}
- 
--	return ret;
-+	return retval;
- }
- 
---- src/kernel/codezero/src/api/thread.c
-+++ src/kernel/codezero/src/api/thread.c
-@@ -497,7 +497,7 @@ out_err:
-  */
- int sys_thread_control(unsigned int flags, struct task_ids *ids)
- {
--	struct ktcb *task = 0, *pager = 0;
-+	struct ktcb *task = 0;
- 	int err, ret = 0;
- 
- 	if ((err = check_access((unsigned long)ids, sizeof(*ids),
-@@ -508,8 +508,6 @@ int sys_thread_control(unsigned int flags, struct task_ids *ids)
- 		if (!(task = tcb_find(ids->tid)))
- 			return -ESRCH;
- 
--		pager = task->pager;
--
- 		/*
- 		 * Caller may operate on a thread if it shares
- 		 * the same address space with that thread's pager
---- src/kernel/codezero/src/arch/arm/mapping-common.c
-+++ src/kernel/codezero/src/arch/arm/mapping-common.c
-@@ -313,12 +313,11 @@ int check_mapping(unsigned long vaddr, unsigned long size,
- int remove_mapping_space(struct address_space *space, unsigned long vaddr)
- {
- 	pmd_table_t *pmd_table;
--	int pgd_i, pmd_i;
-+	int pmd_i;
- 	pmd_t *pmd;
- 	unsigned int pmd_type, pte_type;
- 
- 	vaddr = page_align(vaddr);
--	pgd_i = PGD_INDEX(vaddr);
- 	pmd_i = PMD_INDEX(vaddr);
- 
- 	/*
---- src/kernel/codezero/src/glue/arm/init.c
-+++ src/kernel/codezero/src/glue/arm/init.c
-@@ -68,8 +68,6 @@ void print_sections(void)
- /* The kip is non-standard, using 0xBB to indicate mine for now ;-) */
- void kip_init()
- {
--	struct utcb **utcb_ref;
--
- 	/*
- 	 * TODO: Adding utcb size might be useful
- 	 */
-@@ -86,9 +84,6 @@ void kip_init()
- 
- 	kip_init_syscalls();
- 
--	/* KIP + 0xFF0 is pointer to UTCB segment start address */
--	utcb_ref = (struct utcb **)((unsigned long)&kip + UTCB_KIP_OFFSET);
--
- 	add_boot_mapping(virt_to_phys(&kip), USER_KIP_PAGE, PAGE_SIZE,
- 			 MAP_USR_RO);
- 	printk("%s: Kernel built on %s, %s\n", __KERNELNAME__,
---- src/kernel/codezero/loader/libs/elf/src/elf.c
-+++ src/kernel/codezero/loader/libs/elf/src/elf.c
-@@ -339,16 +339,12 @@ elf_loadFile(void *elfFile, bool phys)
- {
- 	int i;
- 	int num_pheaders;
--	int pheader_offset;
--	int pheader_type;
- 	if (elf_checkFile(elfFile) != 0) {
- 		return false;
- 	}
- 
- 	num_pheaders = elf_getNumProgramHeaders(elfFile);
--	pheader_offset = elf_getProgramHeaderOffset(elfFile, 0);
- 	//printf("Number of program headers: %d\n", num_pheaders);
--	//printf("Program header offset of first header from file beginning: 0x%p\n",pheader_offset);
- 
- 	/*
- 	 * FIXME:
-@@ -373,8 +369,6 @@ elf_loadFile(void *elfFile, bool phys)
- 	//	printf("This section's size in file: %p\n", len);
- 		src = (uint64_t) (uintptr_t) elfFile + elf_getProgramHeaderOffset(elfFile, i);
- 	//	printf("Elf program header offset: %p\n", src);
--		pheader_type = elf_getProgramHeaderType(elfFile, i);
--	//	printf("Elf program header type: %p\n", pheader_type);
- // Comment
- printf("Copying to range from 0x%x to 0x%x of size: 0x%x\n", (unsigned int)dest, (unsigned int)dest + (unsigned int)len, (unsigned int)len);
- 		memcpy((void*) (uintptr_t) dest, (void*) (uintptr_t) src, len);
---- src/kernel/codezero/loader/libs/elf/src/elf32.c
-+++ src/kernel/codezero/loader/libs/elf/src/elf32.c
-@@ -248,7 +248,6 @@ elf32_fprintf(FILE *f, struct Elf32_Header *file, int size, const char *name, in
- 	struct Elf32_Shdr *sections;
- 	unsigned numSections;
- 	int i, r;
--	char *str_table;
- 
- 	fprintf(f, "Found an elf32 file called \"%s\" located "
- 		"at address 0x%p\n", name, file);
-@@ -307,7 +306,6 @@ elf32_fprintf(FILE *f, struct Elf32_Header *file, int size, const char *name, in
- 		}
- 	}
- 	if (flags & ELF_PRINT_SECTIONS) {
--		str_table = elf32_getSegmentStringTable(file);
- 
- 		printf("Section Headers:\n");
- 		printf("  [Nr] Name              Type            Addr     Off\n");
---- src/kernel/codezero/src/generic/capability.c
-+++ src/kernel/codezero/src/generic/capability.c
-@@ -403,7 +403,7 @@ struct capability *cap_match_mem(struct capability *cap,
- {
- 	struct sys_map_args *args = args_ptr;
- 	struct ktcb *target = args->task;
--	unsigned long long start, end, pfn_point;
-+	unsigned long long start, pfn_point;
- 	unsigned long pfn;
- 	unsigned int perms;
- 
-@@ -415,7 +415,6 @@ struct capability *cap_match_mem(struct capability *cap,
- 
- 	/* Long long range check to avoid overflow */
- 	start = cap->start;
--	end = cap->end;
- 	pfn_point = pfn;
- 	if (start > pfn_point || cap->end < pfn_point + args->npages)
- 		return 0;
---- src/kernel/codezero/loader/main.c
-+++ src/kernel/codezero/loader/main.c
-@@ -26,7 +26,6 @@ int load_elf_image(unsigned long **entry, void *filebuf);
- int load_container_image(void *cont_section)
- {
- 	struct Elf32_Header *elf_header = (struct Elf32_Header *)cont_section;
--	struct Elf32_Shdr *sect_header;
- 	int nsect;
- 	int nimgs = 0;
- 	unsigned long *image_entry;
-@@ -36,7 +35,6 @@ int load_container_image(void *cont_section)
- 		return -1;
- 	}
- 
--	sect_header = elf32_getSectionTable(elf_header);
- 	nsect = elf32_getNumSections(elf_header);
- 
- 	for (int i = 0; i < nsect; i++) {
-@@ -59,7 +57,6 @@ int load_container_image(void *cont_section)
- int load_container_images(unsigned long start, unsigned long end)
- {
- 	struct Elf32_Header *elf_header = (struct Elf32_Header *)start;
--	struct Elf32_Shdr *sect_header;
- 	int nsect = 0;
- 	int nconts = 0;
- 
-@@ -68,7 +65,6 @@ int load_container_images(unsigned long start, unsigned long end)
- 		return -1;
- 	}
- 
--	sect_header = elf32_getSectionTable(elf_header);
- 	nsect = elf32_getNumSections(elf_header);
- 
- 	for (int i = 0; i < nsect; i++) {

repos/base-codezero/patches/gcc_shared_enabled.patch

@@ -1,8 +0,0 @@
---- src/kernel/codezero/loader/main.c
-+++ src/kernel/codezero/loader/main.c
-@@ -135,3 +135,5 @@ int main(void)
- 	return -1;
- }
- 
-+
-+asm(".global __aeabi_unwind_cpp_pr0; __aeabi_unwind_cpp_pr0:");

repos/base-codezero/patches/libc_search_dir.patch

@@ -1,19 +0,0 @@
---- src/kernel/codezero/conts/userlibs/SConstruct
-+++ src/kernel/codezero/conts/userlibs/SConstruct
-@@ -11,6 +11,7 @@ PROJRELROOT = '../..'
- sys.path.append(PROJRELROOT)
- 
- from scripts.config.config_invoke import *
-+from scripts.config.projpaths import *
- 
- config = configuration_retrieve()
- gcc_arch_flag = config.gcc_arch_flag
-@@ -28,7 +29,7 @@ env = Environment(CC = config.toolchain_userspace + 'gcc',
-                   ASFLAGS = ['-D__ASSEMBLY__', '-march=' + gcc_arch_flag],
-                   ENV = {'PATH' : os.environ['PATH']},
-                   LIBS = 'gcc',	# libgcc.a - Required for division routines.
--                  CPPPATH = KERNEL_HEADERS,
-+                  CPPPATH = [KERNEL_HEADERS, LIBC_INCLUDE],
-                   CPPFLAGS = '-include l4/config.h -include l4/macros.h -include l4/types.h')
- 
- # Set the build directory for this source tree

repos/base-codezero/patches/scons-2.0.1.patch

@@ -1,91 +0,0 @@
---- src/kernel/codezero/src/drivers/SConscript
-+++ src/kernel/codezero/src/drivers/SConscript
-@@ -8,24 +8,24 @@ src_local = []
- objs = []
- 
- objs += SConscript("uart/pl011/SConscript", exports = { 'env' : env },
--                   duplicate=0, build_dir = join(bdir, 'pl011'))
-+                   duplicate=0, variant_dir = join(bdir, 'pl011'))
- 
- objs += SConscript("timer/sp804/SConscript", exports = { 'env' : env },
--                   duplicate=0, build_dir = join(bdir, 'timer'))
-+                   duplicate=0, variant_dir = join(bdir, 'timer'))
- 
- objs += SConscript("irq/pl190/SConscript", exports = { 'env' : env },
--                   duplicate=0, build_dir = join(bdir, 'vic'))
-+                   duplicate=0, variant_dir = join(bdir, 'vic'))
- 
- objs += SConscript("irq/gic/SConscript", exports = { 'env' : env },
--                   duplicate=0, build_dir = join(bdir, 'gic'))
-+                   duplicate=0, variant_dir = join(bdir, 'gic'))
- 
- objs += SConscript("irq/omap3/SConscript", exports = { 'env' : env },
--                   duplicate=0, build_dir = join(bdir, 'omap/intc'))
-+                   duplicate=0, variant_dir = join(bdir, 'omap/intc'))
- 
- objs += SConscript("uart/omap/SConscript", exports = { 'env' : env },
--                   duplicate=0, build_dir = join(bdir, 'omap/uart'))
-+                   duplicate=0, variant_dir = join(bdir, 'omap/uart'))
- 
- objs += SConscript("timer/omap/SConscript", exports = { 'env' : env },
--                   duplicate=0, build_dir = join(bdir, 'omap/timer'))
-+                   duplicate=0, variant_dir = join(bdir, 'omap/timer'))
- 
- Return('objs')
---- src/kernel/codezero/conts/baremetal/empty/SConstruct
-+++ src/kernel/codezero/conts/baremetal/empty/SConstruct
-@@ -48,7 +48,7 @@ env = Environment(CC = config.toolchain_userspace + 'gcc',
- 		          CPPFLAGS = '-include l4/config.h -include l4/macros.h -include l4/types.h')
- 
- objs = SConscript('SConscript', exports = { 'env' : env },
--                  duplicate=0, build_dir = builddir)
-+                  duplicate=0, variant_dir = builddir)
- 
- Depends(objs, join(PROJROOT, CONFIG_H))
- prog = env.Program(join(builddir, 'main.elf'), objs)
---- src/kernel/codezero/SConstruct
-+++ src/kernel/codezero/SConstruct
-@@ -71,35 +71,35 @@ env = Environment(CC = config.toolchain_kernel + 'gcc',
- objects = []
- objects += SConscript('src/generic/SConscript',
-                       exports = { 'env' : env }, duplicate = 0,
--                      build_dir = join(builddir, 'generic'))
-+                      variant_dir = join(builddir, 'generic'))
- 
- objects += SConscript(join(join('src/glue', arch), 'SConscript'),
-                       exports = { 'env' : env }, duplicate = 0,
--                      build_dir = join(builddir, join('glue',arch)))
-+                      variant_dir = join(builddir, join('glue',arch)))
- 
- objects += SConscript(join(join('src/arch', arch), 'SConscript'),
-                       exports = { 'env' : env }, duplicate = 0,
--                      build_dir = join(builddir, join('arch', arch)))
-+                      variant_dir = join(builddir, join('arch', arch)))
- 
- objects += SConscript(join(join('src/arch', arch), join(subarch, 'SConscript')),
-                       exports = { 'env' : env }, duplicate = 0,
--                      build_dir = join(builddir, join(join('arch',arch), subarch)))
-+                      variant_dir = join(builddir, join(join('arch',arch), subarch)))
- 
- objects += SConscript('src/lib/SConscript',
-                       exports = { 'env' : env }, duplicate = 0,
--                      build_dir = join(builddir, 'lib'))
-+                      variant_dir = join(builddir, 'lib'))
- 
- objects += SConscript('src/api/SConscript',
-                       exports = { 'env' : env }, duplicate = 0,
--                      build_dir = join(builddir, 'api'))
-+                      variant_dir = join(builddir, 'api'))
- 
- objects += SConscript('src/drivers/SConscript',
-                       exports = { 'env' : env, 'bdir' : 'driver/'}, duplicate = 0,
--                      build_dir = join(builddir, 'driver'))
-+                      variant_dir = join(builddir, 'driver'))
- 
- objects += SConscript(join(join('src/platform', platform), 'SConscript'),
-                       exports = { 'env' : env }, duplicate = 0,
--                      build_dir = join(builddir, join('platform', platform)))
-+                      variant_dir = join(builddir, join('platform', platform)))
- 
- 
- # Add builders for generating kernel linker scripts

repos/base-codezero/patches/set_fixed_pager.patch

@@ -1,11 +0,0 @@
---- src/kernel/codezero/include/l4/generic/tcb.h
-+++ src/kernel/codezero/include/l4/generic/tcb.h
-@@ -70,7 +70,7 @@ struct task_ids {
- 
- struct container;
- 
--#define tcb_pagerid(tcb)	((tcb)->pager->tid)
-+#define tcb_pagerid(tcb) 4
- 
- #define space_is_pager(tcb)	\
- 	((tcb)->space->spid == (tcb)->pager->space->spid)

repos/base-codezero/ports/codezero.hash

@@ -1 +0,0 @@
-fb29b6a49c1e6ee759e034da8a59cf66b7ed74ef

repos/base-codezero/ports/codezero.port

@@ -1,9 +0,0 @@
-LICENSE   := GPLv3
-VERSION   := git
-DOWNLOADS := codezero.git
-
-URL(codezero) := https://github.com/nfeske/codezero.git
-REV(codezero) := 6fa4884a5a1cf6207372f69ae01e5faa6d5a39c8
-DIR(codezero) := src/kernel/codezero
-
-PATCHES := $(wildcard $(REP_DIR)/patches/*.patch)

repos/base-codezero/src/base/console/pl011/core_console.h

@@ -1,78 +0,0 @@
-/*
- * \brief  Console backend for PL011 UART on Codezero
- * \author Norman Feske
- * \date   2009-10-03
- *
- * This code assumes a PL011 UART as provided by 'qemu -M versatilepb'. Prior
- * executing this code, the kernel already initialized the UART to print some
- * startup message. So we can skip the UART initialization here. The kernel
- * maps the UART registers to the magic address PL011_BASE when starting mm0.
- * So we can just start using the device without any precautions.
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/console.h>
-
-/* codezero includes */
-#include <codezero/syscalls.h>
-
-typedef unsigned char uint8_t;
-
-/**
- * Base address of default-mapped UART device
- *
- * defined in 'l4/arch/arm/io.h'
- */
-enum { PL011_BASE = USERSPACE_CONSOLE_VBASE };
-
-/**
- * UART registers
- */
-enum { PL011_REG_UARTDR = PL011_BASE + 0x00 };
-enum { PL011_REG_UARTFR = PL011_BASE + 0x18 };
-
-
-/**
- * Returns true if UART is ready to transmit a character
- */
-static bool pl011_tx_ready()
-{
-	enum { PL011_TX_FIFO_FULL = 1 << 5 };
-	return !(*((volatile unsigned *)PL011_REG_UARTFR) & PL011_TX_FIFO_FULL);
-}
-
-
-/**
- * Output character to serial port
- */
-static void pl011_out_char(uint8_t c)
-{
-	/* wait until serial port is ready */
-	while (!pl011_tx_ready());
-
-	/* output character */
-	*((volatile unsigned int *)PL011_REG_UARTDR) = c;
-}
-
-
-namespace Genode
-{
-	class Core_console : public Console
-	{
-		protected:
-
-			void _out_char(char c) {
-				if(c == '\n')
-					pl011_out_char('\r');
-				pl011_out_char(c);
-			}
-	};
-}
-

repos/base-codezero/src/base/cxx/exception.cc

@@ -1,53 +0,0 @@
-/*
- * \brief  Support for exceptions libsupc++
- * \author Norman Feske
- * \author Sebastian Sumpf
- * \date   2006-07-21
- */
-
-/*
- * Copyright (C) 2006-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#include <base/printf.h>
-
-extern "C" char __eh_frame_start__[];                  /* from linker script */
-extern "C" void __register_frame (const void *begin);  /* from libgcc_eh     */
-
-/*
- * This symbol is set by Genode's dynamic linker (ldso) during binary setup.
- * After setup, the symbol will point to the actual implementation of
- * 'dl_iterate_phdr', which is located within the linker. 'dl_iterate_phdr'
- * iterates through all (linker loaded) binaries and shared libraries. This
- * function has to be implemented in order to support C++ exceptions within
- * shared libraries.
- * Return values of dl_iterate_phdr (gcc 4.2.4):
- *   < 0 = error
- *     0 = continue program header iteration
- *   > 0 = stop iteration (no errors occured)
- *
- * See also: man dl_iterate_phdr
- */
-int (*genode__dl_iterate_phdr) (int (*callback) (void *info, unsigned long size, void *data), void *data) = 0;
-
-extern "C" int dl_iterate_phdr(int (*callback) (void *info, unsigned long size, void *data), void *data) __attribute__((weak));
-extern "C" int dl_iterate_phdr(int (*callback) (void *info, unsigned long size, void *data), void *data)
-{
-	if (!genode__dl_iterate_phdr)
-		return -1;
-
-	return genode__dl_iterate_phdr(callback, data);
-}
-
-extern "C" void raise()
-{
-	PDBG("raise called - not implemented\n");
-}
-
-void init_exception_handling()
-{
-//	__register_frame(__eh_frame_start__);
-}

repos/base-codezero/src/base/cxx/memcmp.cc

@@ -1,24 +0,0 @@
-/*
- * \brief  Functions required for using the arm-none-linux-gnueabi tool chain
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#include <base/printf.h>
-#include <base/stdint.h>
-
-using namespace Genode;
-
-
-extern "C" int raise(int sig)
-{
-	PWRN("raise - not yet implemented");
-	return 0;
-}

repos/base-codezero/src/base/env/utcb.cc

@@ -1,30 +0,0 @@
-/*
- * \brief  Helper functions UTCB access on Codezero
- * \author Norman Feske
- * \date   2012-03-01
- */
-
-/*
- * Copyright (C) 2012-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/thread.h>
-
-
-Genode::Native_utcb *Genode::Thread_base::utcb()
-{
-	/*
-	 * If 'utcb' is called on the object returned by 'myself',
-	 * the 'this' pointer may be NULL (if the calling thread is
-	 * the main thread). Therefore we handle this special case
-	 * here.
-	 */
-	if (this == 0) return 0;
-
-	return &_context->utcb;
-}
-

repos/base-codezero/src/base/ipc/ipc.cc

@@ -1,175 +0,0 @@
-/*
- * \brief  Codezero implementation of the IPC API
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-/* Genode includes */
-#include <base/ipc.h>
-#include <base/printf.h>
-#include <base/blocking.h>
-#include <util/misc_math.h>
-
-using namespace Genode;
-using namespace Codezero;
-
-enum { verbose_ipc = false };
-
-
-/*****************
- ** Ipc_ostream **
- *****************/
-
-void Ipc_ostream::_send()
-{
-	if (verbose_ipc)
-		PDBG("thread %d sends IPC to %d, write_offset=%d",
-		     thread_myself(), _dst.dst(), _write_offset);
-
-	umword_t snd_size = min(_write_offset, (unsigned)L4_IPC_EXTENDED_MAX_SIZE);
-
-	*(umword_t *)_snd_msg->addr() = _dst.local_name();
-
-	int ret = l4_send_extended(_dst.dst(), L4_IPC_TAG_SYNC_EXTENDED,
-	                           snd_size, _snd_msg->addr());
-	if (ret < 0)
-		PERR("l4_send_extended (to thread %d) returned ret=%d",
-		     _dst.dst(), ret);
-
-	_write_offset = sizeof(umword_t);
-}
-
-
-
-Ipc_ostream::Ipc_ostream(Native_capability dst, Msgbuf_base *snd_msg)
-:
-	Ipc_marshaller((char *)snd_msg->addr(), snd_msg->size()),
-	_snd_msg(snd_msg), _dst(dst)
-{
-	_write_offset = sizeof(umword_t);
-}
-
-
-/*****************
- ** Ipc_istream **
- *****************/
-
-void Ipc_istream::_wait()
-{
-	umword_t *rcv_buf = (umword_t *)_rcv_msg->addr();
-	umword_t rcv_size = min(_rcv_msg->size(), (unsigned)L4_IPC_EXTENDED_MAX_SIZE);
-
-	if (verbose_ipc)
-		PDBG("thread %d waits for IPC from %d, rcv_buf at %p, rcv_size=%d",
-		     dst(), _rcv_cs, rcv_buf, (int)rcv_size);
-
-	int ret = l4_receive_extended(_rcv_cs, rcv_size, rcv_buf);
-	if (ret < 0)
-		PERR("l4_receive_extended (from any) returned ret=%d", ret);
-
-	if (verbose_ipc)
-		PDBG("thread %d received IPC from %d",
-		     dst(), l4_get_sender());
-
-	_read_offset = sizeof(umword_t);
-}
-
-
-Ipc_istream::Ipc_istream(Msgbuf_base *rcv_msg)
-:
-	Ipc_unmarshaller((char *)rcv_msg->addr(), rcv_msg->size()),
-	Native_capability(thread_myself(), 0),
-	_rcv_msg(rcv_msg)
-{
-	_rcv_cs = L4_ANYTHREAD;
-	_read_offset = sizeof(umword_t);
-}
-
-
-Ipc_istream::~Ipc_istream() { }
-
-
-/****************
- ** Ipc_client **
- ****************/
-
-void Ipc_client::_call()
-{
-#warning l4_sendrecv_extended is not yet implemented in l4lib/arch/syslib.h
-	_send();
-	_rcv_cs = Ipc_ostream::_dst.dst();
-	_wait();
-	_rcv_cs = L4_ANYTHREAD;
-
-	_write_offset = _read_offset = sizeof(umword_t);
-}
-
-
-Ipc_client::Ipc_client(Native_capability const &srv, Msgbuf_base *snd_msg,
-                       Msgbuf_base *rcv_msg, unsigned short)
-: Ipc_istream(rcv_msg), Ipc_ostream(srv, snd_msg), _result(0)
-{ }
-
-
-/****************
- ** Ipc_server **
- ****************/
-
-void Ipc_server::_prepare_next_reply_wait()
-{
-	/* now we have a request to reply */
-	_reply_needed = true;
-
-	/* leave space for return value at the beginning of the msgbuf */
-	_write_offset = 2*sizeof(umword_t);
-
-	/* receive buffer offset */
-	_read_offset = sizeof(umword_t);
-}
-
-
-void Ipc_server::_wait()
-{
-	/* wait for new server request */
-	try { Ipc_istream::_wait(); } catch (Blocking_canceled) { }
-
-	/* define destination of next reply */
-	Ipc_ostream::_dst = Native_capability(l4_get_sender(), badge());
-
-	_prepare_next_reply_wait();
-}
-
-
-void Ipc_server::_reply()
-{
-	try { _send(); } catch (Ipc_error) { }
-
-	_prepare_next_reply_wait();
-}
-
-
-void Ipc_server::_reply_wait()
-{
-	if (_reply_needed)
-		_reply();
-
-	_wait();
-}
-
-
-Ipc_server::Ipc_server(Msgbuf_base *snd_msg,
-                       Msgbuf_base *rcv_msg)
-:
-	Ipc_istream(rcv_msg), Ipc_ostream(Native_capability(), snd_msg),
-	_reply_needed(false)
-{ }

repos/base-codezero/src/base/ipc/pager.cc

@@ -1,175 +0,0 @@
-/*
- * \brief  Pager support for Codezero
- * \author Norman Feske
- * \date   2010-02-16
- */
-
-/*
- * Copyright (C) 2010-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/ipc_pager.h>
-#include <base/printf.h>
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-
-using namespace Genode;
-using namespace Codezero;
-
-enum { verbose_page_faults = false };
-
-
-/************************
- ** Page-fault utility **
- ************************/
-
-class Fault
-{
-	public:
-
-		enum Type { READ, WRITE, EXEC, UNKNOWN };
-
-	private:
-
-		/**
-		 * Translate Codezero page-fault information to generic fault type
-		 *
-		 * \param sr status
-		 * \param pte page-table entry
-		 */
-		static Type _fault_type(umword_t sr, umword_t pte)
-		{
-			if (is_prefetch_abort(sr))
-				return EXEC;
-
-			if ((pte & PTE_PROT_MASK) == (__MAP_USR_RO & PTE_PROT_MASK))
-				return WRITE;
-
-			return READ;
-		}
-
-		Type     _type;
-		umword_t _addr;
-		umword_t _ip;
-
-	public:
-
-		/**
-		 * Constructor
-		 *
-		 * \param kdata  Codezero-specific page-fault information
-		 */
-		Fault(struct fault_kdata const &kdata)
-		:
-			_type(_fault_type(kdata.fsr, kdata.pte)),
-			_addr(_type == EXEC ? kdata.faulty_pc : kdata.far),
-			_ip(kdata.faulty_pc)
-		{ }
-
-		Type     type() const { return _type; }
-		umword_t addr() const { return _addr; }
-		umword_t ip()   const { return _ip; }
-};
-
-
-/**
- * Print page-fault information in a human-readable form
- */
-inline void print_page_fault(Fault &fault, int from)
-{
-	printf("page (%s%s%s) fault from %d at pf_addr=%lx, pf_ip=%lx\n",
-	       fault.type() == Fault::READ  ? "r"  : "-",
-	       fault.type() == Fault::WRITE ? "w"  : "-",
-	       fault.type() == Fault::EXEC  ? "x"  : "-",
-	       from, fault.addr(), fault.ip());
-}
-
-
-/***************
- ** IPC pager **
- ***************/
-
-void Ipc_pager::wait_for_fault()
-{
-	for (;;) {
-		int ret = l4_receive(L4_ANYTHREAD);
-
-		if (ret < 0) {
-			PERR("pager: l4_received returned ret=%d", ret);
-			continue;
-		}
-
-		umword_t tag         = l4_get_tag();
-		int      faulter_tid = l4_get_sender();
-
-		if (tag != L4_IPC_TAG_PFAULT) {
-			PWRN("got an unexpected IPC from %d", faulter_tid);
-			continue;
-		}
-
-		/* copy fault information from message registers */
-		struct fault_kdata fault_kdata;
-		for (unsigned i = 0; i < sizeof(fault_kdata_t)/sizeof(umword_t); i++)
-			((umword_t *)&fault_kdata)[i] = read_mr(MR_UNUSED_START + i);
-
-		Fault fault(fault_kdata);
-
-		if (verbose_page_faults)
-			print_page_fault(fault, faulter_tid);
-
-		/* determine corresponding page in our own address space */
-		_pf_addr  = fault.addr();
-		_pf_write = fault.type() == Fault::WRITE;
-		_pf_ip    = fault.ip();
-		_last     = faulter_tid;
-
-		return;
-	}
-}
-
-
-void Ipc_pager::reply_and_wait_for_fault()
-{
-	/* install mapping */
-	umword_t flags = _reply_mapping.writeable() ? MAP_USR_RW
-	                                            : MAP_USR_RO;
-	
-	/*
-	 * XXX: remove heuristics for mapping device registers.
-	 */
-	if (_reply_mapping.from_phys() == 0x10120000  /* LCD */
-	 || _reply_mapping.from_phys() == 0x10006000  /* keyboard */
-	 || _reply_mapping.from_phys() == 0x10007000) /* mouse */
-		flags = MAP_USR_IO;
-
-	int ret = l4_map((void *)_reply_mapping.from_phys(),
-	                 (void *)_reply_mapping.to_virt(),
-	                 _reply_mapping.num_pages(), flags, _last);
-
-	/* wake up faulter if mapping succeeded */
-	if (ret < 0)
-		PERR("l4_map returned %d, putting thread %d to sleep", ret, _last);
-	else
-		acknowledge_wakeup();
-
-	/* wait for next page fault */
-	wait_for_fault();
-}
-
-
-void Ipc_pager::acknowledge_wakeup()
-{
-	enum { SUCCESS = 0 };
-	l4_set_sender(_last);
-	l4_ipc_return(SUCCESS);
-}
-
-
-Ipc_pager::Ipc_pager() : Native_capability(thread_myself(), 0) { }
-

repos/base-codezero/src/base/lock/cmpxchg.cc

@@ -1,48 +0,0 @@
-/*
- * \brief  Codezero-specific implementation of cmpxchg
- * \author Norman Feske
- * \date   2009-10-12
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <cpu/atomic.h>
-#include <base/printf.h>
-#include <base/lock.h>
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-
-static bool mutex_initialized;
-static Codezero::l4_mutex mutex;
-
-int Genode::cmpxchg(volatile int *dest, int cmp_val, int new_val)
-{
-	if (!mutex_initialized) {
-		Codezero::l4_mutex_init(&mutex);
-		mutex_initialized = true;
-	}
-
-	int ret = Codezero::l4_mutex_lock(&mutex);
-	if (ret < 0)
-		mutex_initialized = false;
-
-	bool result = false;
-	if (*dest == cmp_val) {
-		*dest = new_val;
-		result = true;
-	}
-
-	ret = Codezero::l4_mutex_unlock(&mutex);
-	if (ret < 0)
-		mutex_initialized = false;
-
-	return result;
-}

repos/base-codezero/src/base/lock/lock_helper.h

@@ -1,61 +0,0 @@
-/*
- * \brief  Helper functions for the Lock implementation
- * \author Norman Feske
- * \date   2010-04-20
- *
- * For documentation about the interface, please revisit the 'base-pistachio'
- * implementation.
- */
-
-/*
- * Copyright (C) 2010-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/native_types.h>
-#include <base/thread.h>
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-
-extern Genode::Native_thread_id main_thread_tid;
-extern Codezero::l4_mutex       main_thread_running_lock;
-
-
-static inline void thread_yield()
-{
-	Codezero::l4_thread_switch(-1);
-}
-
-
-static inline bool thread_check_stopped_and_restart(Genode::Thread_base *thread_base)
-{
-	Codezero::l4_mutex *running_lock = thread_base ?
-	                                   thread_base->utcb()->running_lock() :
-	                                   &main_thread_running_lock;
-	Codezero::l4_mutex_unlock(running_lock);
-	return true;
-}
-
-
-static inline void thread_switch_to(Genode::Thread_base *thread_base)
-{
-	Genode::Native_thread_id tid = thread_base ?
-	                               thread_base->tid().l4id :
-	                               main_thread_tid;
-	Codezero::l4_thread_switch(tid);
-}
-
-
-static inline void thread_stop_myself()
-{
-	Genode::Thread_base *myself = Genode::Thread_base::myself();
-	Codezero::l4_mutex *running_lock = myself ?
-	                                   myself->utcb()->running_lock() :
-	                                   &main_thread_running_lock;
-	Codezero::l4_mutex_lock(running_lock);
-}

repos/base-codezero/src/base/pager/pager.cc

@@ -1,105 +0,0 @@
-/*
- * \brief  Dummy pager framework
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/pager.h>
-
-using namespace Genode;
-
-
-/**********************
- ** Pager activation **
- **********************/
-
-void Pager_activation_base::entry()
-{
-	Ipc_pager pager;
-	_cap = pager;
-	_cap_valid.unlock();
-
-	bool reply = false;
-
-	while (1) {
-
-		if (reply)
-			pager.reply_and_wait_for_fault();
-		else
-			pager.wait_for_fault();
-
-		/* lookup referenced object */
-		Object_pool<Pager_object>::Guard _obj(_ep ? _ep->lookup_and_lock(pager.badge()) : 0);
-		Pager_object * obj = _obj;
-		reply = false;
-
-		/* handle request */
-		if (obj) {
-			reply = !obj->pager(pager);
-			/* something strange occurred - leave thread in pagefault */
-			continue;
-		}
-
-		/*
-		 * We got a request from one of cores region-manager sessions
-		 * to answer the pending page fault of a resolved region-manager
-		 * client. Hence, we have to send the page-fault reply to the
-		 * specified thread and answer the call of the region-manager
-		 * session.
-		 *
-		 * When called from a region-manager session, we receive the
-		 * core-local address of the targeted pager object via the
-		 * first message word, which corresponds to the 'fault_ip'
-		 * argument of normal page-fault messages.
-		 */
-		obj = reinterpret_cast<Pager_object *>(pager.fault_ip());
-
-		/* send reply to the calling region-manager session */
-		pager.acknowledge_wakeup();
-
-		/* answer page fault of resolved pager object */
-		pager.set_reply_dst(obj->cap());
-		pager.acknowledge_wakeup();
-	}
-}
-
-
-/**********************
- ** Pager entrypoint **
- **********************/
-
-Pager_entrypoint::Pager_entrypoint(Cap_session *, Pager_activation_base *a)
-: _activation(a)
-{ _activation->ep(this); }
-
-
-void Pager_entrypoint::dissolve(Pager_object *obj)
-{
-	remove_locked(obj);
-}
-
-
-Pager_capability Pager_entrypoint::manage(Pager_object *obj)
-{
-	/* return invalid capability if no activation is present */
-	if (!_activation) return Pager_capability();
-
-	_activation->cap();
-
-	Untyped_capability cap = Native_capability(_activation->cap().dst(), obj->badge());
-
-	/* add server object to object pool */
-	obj->cap(cap);
-	insert(obj);
-
-	/* return capability that uses the object id as badge */
-	return reinterpret_cap_cast<Pager_object>(cap);
-}

repos/base-codezero/src/base/thread/thread_bootstrap.cc

@@ -1,96 +0,0 @@
-/*
- * \brief  Thread bootstrap code
- * \author Christian Prochaska
- * \author Martin Stein
- * \date   2013-02-15
- */
-
-/*
- * Copyright (C) 2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/thread.h>
-#include <base/env.h>
-#include <util/string.h>
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-Genode::Native_thread_id main_thread_tid;
-Codezero::l4_mutex       main_thread_running_lock;
-
-
-/*****************************
- ** Startup library support **
- *****************************/
-
-void prepare_init_main_thread()
-{
-	/* initialize codezero environment */
-	Codezero::__l4_init();
-
-	/* provide kernel identification of thread through temporary environment */
-	main_thread_tid = Codezero::thread_myself();
-}
-
-void prepare_reinit_main_thread() { prepare_init_main_thread(); }
-
-
-/****************************
- ** Codezero libl4 support **
- ****************************/
-
-/*
- * Unfortunately, the function 'exregs_print_registers' in 'exregs.c' refers to
- * 'memset'. Because we do not want to link core against a C library, we have to
- * resolve this function here.
- */
-extern "C" void *memset(void *s, int c, Genode::size_t n) __attribute__((weak));
-extern "C" void *memset(void *s, int c, Genode::size_t n)
-{
-	return Genode::memset(s, c, n);
-}
-
-
-/*
- * Same problem as for 'memset'. The 'printf' symbol is referenced from
- * 'mutex.c' and 'exregs.c' of Codezero's libl4.
- */
-extern "C" int printf(const char *format, ...) __attribute__((weak));
-extern "C" int printf(const char *format, ...)
-{
-	va_list list;
-	va_start(list, format);
-	Genode::vprintf(format, list);
-	va_end(list);
-	return 0;
-}
-
-
-/*****************
- ** Thread_base **
- *****************/
-
-void Genode::Thread_base::_thread_bootstrap()
-{
-	Codezero::l4_mutex_init(utcb()->running_lock());
-	Codezero::l4_mutex_lock(utcb()->running_lock()); /* block on first mutex lock */
-}
-
-
-void Genode::Thread_base::_init_platform_thread(size_t, Type type)
-{
-	if (type == NORMAL) { return; }
-
-	/* adjust values whose computation differs for a main thread */
-	_tid.l4id = main_thread_tid;
-	_thread_cap = Genode::env()->parent()->main_thread_cap();
-
-	/* get first mutex lock (normally done by _thread_bootstrap) */
-	Codezero::l4_mutex_init(utcb()->running_lock());
-	Codezero::l4_mutex_lock(utcb()->running_lock());
-}

repos/base-codezero/src/base/thread/thread_start.cc

@@ -1,77 +0,0 @@
-/*
- * \brief  NOVA-specific implementation of the Thread API
- * \author Norman Feske
- * \date   2010-01-19
- */
-
-/*
- * Copyright (C) 2010-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/thread.h>
-#include <base/printf.h>
-#include <base/sleep.h>
-#include <base/env.h>
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-using namespace Genode;
-
-
-/**
- * Entry point entered by new threads
- */
-void Thread_base::_thread_start()
-{
-	Thread_base::myself()->_thread_bootstrap();
-	Thread_base::myself()->entry();
-	Thread_base::myself()->_join_lock.unlock();
-	Genode::sleep_forever();
-}
-
-
-/*****************
- ** Thread base **
- *****************/
-
-void Thread_base::_deinit_platform_thread()
-{
-	_cpu_session->kill_thread(_thread_cap);
-	env()->rm_session()->remove_client(_pager_cap);
-}
-
-
-void Thread_base::start()
-{
-	/* if no cpu session is given, use it from the environment */
-	if (!_cpu_session)
-		_cpu_session = env()->cpu_session();
-
-	/* create thread at core */
-	char buf[48];
-	name(buf, sizeof(buf));
-	enum { WEIGHT = Cpu_session::DEFAULT_WEIGHT };
-	_thread_cap = _cpu_session->create_thread(WEIGHT, buf);
-
-	/* assign thread to protection domain */
-	env()->pd_session()->bind_thread(_thread_cap);
-
-	/* create new pager object and assign it to the new thread */
-	_pager_cap = env()->rm_session()->add_client(_thread_cap);
-	_cpu_session->set_pager(_thread_cap, _pager_cap);
-
-	/* register initial IP and SP at core */
-	_cpu_session->start(_thread_cap, (addr_t)_thread_start, _context->stack_top());
-}
-
-
-void Thread_base::cancel_blocking()
-{
-	Codezero::l4_mutex_unlock(utcb()->running_lock());
-	_cpu_session->cancel_blocking(_thread_cap);
-}

repos/base-codezero/src/core/core_rm_session.cc

@@ -1,68 +0,0 @@
-/*
- * \brief  Core-local RM session
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/printf.h>
-
-/* core includes */
-#include <core_rm_session.h>
-#include <platform.h>
-#include <map_local.h>
-
-using namespace Genode;
-
-
-Rm_session::Local_addr
-Core_rm_session::attach(Dataspace_capability ds_cap, size_t size,
-                        off_t offset, bool use_local_addr,
-                        Rm_session::Local_addr local_addr,
-                        bool executable)
-{
-	using namespace Codezero;
-
-	Object_pool<Dataspace_component>::Guard ds(_ds_ep->lookup_and_lock(ds_cap));
-	if (!ds)
-		throw Invalid_dataspace();
-
-	if (size == 0)
-		size = ds->size();
-
-	size_t page_rounded_size = (size + get_page_size() - 1) & get_page_mask();
-	size_t num_pages         = page_rounded_size >> get_page_size_log2();
-
-	if (use_local_addr) {
-		PERR("Parameter 'use_local_addr' not supported within core");
-		return 0;
-	}
-
-	if (offset) {
-		PERR("Parameter 'offset' not supported within core");
-		return 0;
-	}
-
-	/* allocate range in core's virtual address space */
-	void *virt_addr;
-	if (!platform()->region_alloc()->alloc(page_rounded_size, &virt_addr)) {
-		PERR("Could not allocate virtual address range in core of size %zd\n",
-		     page_rounded_size);
-		return false;
-	}
-
-	if (!map_local(ds->phys_addr(), (addr_t)virt_addr, num_pages)) {
-		PERR("core-local memory mapping failed virt=%lx, phys=%lx\n",
-		     (addr_t)virt_addr, ds->phys_addr());
-		return 0;
-	}
-
-	return virt_addr;
-}

repos/base-codezero/src/core/cpu_session_support.cc

@@ -1,30 +0,0 @@
-/*
- * \brief   Platform-specific parts of cores CPU-service
- * \author  Martin Stein
- * \date    2012-04-17
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/printf.h>
-
-/* Core includes */
-#include <cpu_session_component.h>
-
-using namespace Genode;
-
-
-Ram_dataspace_capability Cpu_session_component::utcb(Thread_capability thread_cap)
-{
-	PERR("%s: Not implemented", __PRETTY_FUNCTION__);
-	return Ram_dataspace_capability();
-}
-
-
-Cpu_session::Quota Cpu_session_component::quota() { return Quota(); }

repos/base-codezero/src/core/include/core_rm_session.h

@@ -1,55 +0,0 @@
-/*
- * \brief  Core-local region manager session
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _CORE__INCLUDE__CORE_RM_SESSION_H_
-#define _CORE__INCLUDE__CORE_RM_SESSION_H_
-
-/* Genode includes */
-#include <rm_session/rm_session.h>
-
-/* core includes */
-#include <dataspace_component.h>
-
-namespace Genode {
-
-	class Core_rm_session : public Rm_session
-	{
-		private:
-
-			Rpc_entrypoint *_ds_ep;
-
-		public:
-
-			Core_rm_session(Rpc_entrypoint *ds_ep) : _ds_ep(ds_ep) { }
-
-			Local_addr attach(Dataspace_capability ds_cap, size_t size = 0,
-			                  off_t offset = 0, bool use_local_addr = false,
-			                  Local_addr local_addr = 0,
-			                  bool executable = false);
-
-			void detach(Local_addr) { }
-
-			Pager_capability add_client(Thread_capability) {
-				return Pager_capability(); }
-
-			void remove_client(Pager_capability) { }
-
-			void fault_handler(Signal_context_capability) { }
-
-			State state() { return State(); }
-
-			Dataspace_capability dataspace() { return Dataspace_capability(); }
-	};
-}
-
-#endif /* _CORE__INCLUDE__CORE_RM_SESSION_H_ */

repos/base-codezero/src/core/include/map_local.h

@@ -1,66 +0,0 @@
-/*
- * \brief  Core-local mapping
- * \author Norman Feske
- * \date   2010-02-15
- */
-
-/*
- * Copyright (C) 2010-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _CORE__INCLUDE__MAP_LOCAL_H_
-#define _CORE__INCLUDE__MAP_LOCAL_H_
-
-/* Genode includes */
-#include <base/printf.h>
-
-/* core includes */
-#include <util.h>
-
-
-namespace Genode {
-
-	/**
-	 * Map physical pages to core-local virtual address range
-	 *
-	 * On Codezero, mappings originate from the physical address space.
-	 *
-	 * \param from_phys  physical source address
-	 * \param to_virt    core-local destination address
-	 * \param num_pages  number of pages to map
-	 *
-	 * \return true on success
-	 */
-	inline bool map_local(addr_t from_phys, addr_t to_virt, size_t num_pages)
-	{
-		using namespace Codezero;
-
-		int res = l4_map((void *)from_phys, (void *)to_virt,
-		                 num_pages, MAP_USR_RW, thread_myself());
-		if (res < 0) {
-			PERR("l4_map phys 0x%lx -> 0x%lx returned %d", from_phys, to_virt, res);
-			return false;
-		}
-
-		return true;
-	}
-
-
-	inline bool unmap_local(addr_t virt_addr, size_t num_pages)
-	{
-		using namespace Codezero;
-
-		int res = l4_unmap((void *)virt_addr, num_pages, thread_myself());
-		if (res < 0) {
-			PERR("l4_unmap returned %d", res);
-			return false;
-		}
-
-		return true;
-	}
-}
-
-#endif /* _CORE__INCLUDE__MAP_LOCAL_H_ */

repos/base-codezero/src/core/include/platform.h

@@ -1,72 +0,0 @@
-/*
- * \brief  Platform interface
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _CORE__INCLUDE__PLATFORM_H_
-#define _CORE__INCLUDE__PLATFORM_H_
-
-/* Genode includes */
-#include <base/printf.h>
-
-/* local includes */
-#include <platform_generic.h>
-#include <core_mem_alloc.h>
-
-namespace Genode {
-
-	class Platform : public Platform_generic
-	{
-		private:
-
-			typedef Core_mem_allocator::Phys_allocator Phys_allocator;
-
-			Core_mem_allocator _core_mem_alloc; /* core-accessible memory */
-			Phys_allocator     _io_mem_alloc;   /* MMIO allocator         */
-			Phys_allocator     _io_port_alloc;  /* I/O port allocator     */
-			Phys_allocator     _irq_alloc;      /* IRQ allocator          */
-			Rom_fs             _rom_fs;         /* ROM file system        */
-
-			/**
-			 * Virtual address range usable by non-core processes
-			 */
-			addr_t _vm_base;
-			size_t _vm_size;
-
-			int _init_rom_fs();
-
-		public:
-
-			/**
-			 * Constructor
-			 */
-			Platform();
-
-
-			/********************************
-			 ** Generic platform interface **
-			 ********************************/
-
-			Range_allocator *ram_alloc()      { return  _core_mem_alloc.phys_alloc(); }
-			Range_allocator *io_mem_alloc()   { return &_io_mem_alloc; }
-			Range_allocator *io_port_alloc()  { return &_io_port_alloc; }
-			Range_allocator *irq_alloc()      { return &_irq_alloc; }
-			Range_allocator *region_alloc()   { return  _core_mem_alloc.virt_alloc(); }
-			Range_allocator *core_mem_alloc() { return &_core_mem_alloc; }
-			addr_t           vm_start() const { return _vm_base; }
-			size_t           vm_size()  const { return _vm_size;  }
-			Rom_fs          *rom_fs()         { return &_rom_fs; }
-
-			void wait_for_exit();
-	};
-}
-
-#endif /* _CORE__INCLUDE__PLATFORM_H_ */

repos/base-codezero/src/core/include/platform_pd.h

@@ -1,90 +0,0 @@
-/*
- * \brief   Protection-domain facility
- * \author  Norman Feske
- * \date    2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _CORE__INCLUDE__PLATFORM_PD_H_
-#define _CORE__INCLUDE__PLATFORM_PD_H_
-
-/* Genode includes */
-#include <base/allocator.h>
-
-/* core includes */
-#include <platform_thread.h>
-#include <address_space.h>
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-namespace Genode {
-
-	class Platform_thread;
-	class Platform_pd : public Address_space
-	{
-		private:
-
-			enum { MAX_THREADS_PER_PD = 32 };
-			enum { UTCB_VIRT_BASE = 0x30000000 };
-			enum { UTCB_AREA_SIZE = MAX_THREADS_PER_PD*sizeof(struct Codezero::utcb) };
-
-			unsigned _space_id;
-
-			bool utcb_in_use[MAX_THREADS_PER_PD];
-
-		public:
-
-			/**
-			 * Constructors
-			 */
-			Platform_pd(bool core);
-			Platform_pd(Allocator * md_alloc, char const *,
-			            signed pd_id = -1, bool create = true);
-
-			/**
-			 * Destructor
-			 */
-			~Platform_pd();
-
-			/**
-			 * Register quota donation at allocator guard
-			 */
-			void upgrade_ram_quota(size_t ram_quota) { }
-
-			/**
-			 * Bind thread to protection domain
-			 *
-			 * \return  0  on success or
-			 *         -1  if thread ID allocation failed.
-			 */
-			int bind_thread(Platform_thread *thread);
-
-			/**
-			 * Unbind thread from protection domain
-			 *
-			 * Free the thread's slot and update thread object.
-			 */
-			void unbind_thread(Platform_thread *thread);
-
-			/**
-			 * Assign parent interface to protection domain
-			 */
-			int assign_parent(Native_capability parent) { return 0; }
-
-
-			/*****************************
-			 ** Address-space interface **
-			 *****************************/
-
-			void flush(addr_t, size_t) { PDBG("not implemented"); }
-	};
-}
-
-#endif /* _CORE__INCLUDE__PLATFORM_PD_H_ */

repos/base-codezero/src/core/include/platform_thread.h

@@ -1,163 +0,0 @@
-/*
- * \brief   Thread facility
- * \author  Norman Feske
- * \date    2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _CORE__INCLUDE__PLATFORM_THREAD_H_
-#define _CORE__INCLUDE__PLATFORM_THREAD_H_
-
-/* Genode includes */
-#include <base/pager.h>
-#include <base/thread_state.h>
-#include <base/native_types.h>
-
-/* core includes */
-#include <address_space.h>
-
-namespace Genode {
-
-	class Platform_pd;
-	class Platform_thread
-	{
-		private:
-
-			friend class Platform_pd;
-
-			enum { PD_NAME_MAX_LEN = 64 };
-
-			unsigned                _tid;   /* global codezero thread ID */
-			unsigned                _space_id;
-			Weak_ptr<Address_space> _address_space;
-			addr_t                  _utcb;
-			char                    _name[PD_NAME_MAX_LEN];
-			Pager_object           *_pager;
-
-			/**
-			 * Assign physical thread ID and UTCB address to thread
-			 *
-			 * This function is called from 'Platform_pd::bind_thread'.
-			 */
-			void _assign_physical_thread(unsigned tid, unsigned space_id,
-			                             addr_t utcb,
-			                             Weak_ptr<Address_space> address_space)
-			{
-				_tid = tid; _space_id = space_id; _utcb = utcb;
-				_address_space = address_space;
-			}
-
-		public:
-
-			enum { THREAD_INVALID = -1 };   /* invalid thread number */
-
-			/**
-			 * Constructor
-			 */
-			Platform_thread(size_t, const char *name = 0, unsigned priority = 0,
-			                addr_t utcb = 0, int thread_id = THREAD_INVALID);
-
-			/**
-			 * Destructor
-			 */
-			~Platform_thread();
-
-			/**
-			 * Start thread
-			 *
-			 * \param ip      instruction pointer to start at
-			 * \param sp      stack pointer to use
-			 * \param cpu_no  target cpu
-			 *
-			 * \retval  0  successful
-			 * \retval -1  thread could not be started
-			 */
-			int start(void *ip, void *sp, unsigned int cpu_no = 0);
-
-			/**
-			 * Pause this thread
-			 */
-			void pause();
-
-			/**
-			 * Resume this thread
-			 */
-			void resume();
-
-			/**
-			 * Cancel currently blocking operation
-			 */
-			void cancel_blocking();
-
-			/**
-			 * Override thread state with 's'
-			 *
-			 * \throw Cpu_session::State_access_failed
-			 */
-			void state(Thread_state s);
-
-			/**
-			 * Read thread state
-			 *
-			 * \throw Cpu_session::State_access_failed
-			 */
-			Thread_state state();
-
-			/**
-			 * Return the address space to which the thread is bound
-			 */
-			Weak_ptr<Address_space> address_space();
-
-
-			/************************
-			 ** Accessor functions **
-			 ************************/
-
-			/**
-			 * Set pager capability
-			 */
-			Pager_object *pager(Pager_object *pager) const { return _pager; }
-			void pager(Pager_object *pager) { _pager = pager; }
-			Pager_object *pager() { return _pager; }
-
-			/**
-			 * Return identification of thread when faulting
-			 */
-			unsigned long pager_object_badge() const { return _tid; }
-
-			/**
-			 * Set the executing CPU for this thread
-			 */
-			void affinity(Affinity::Location) { }
-
-			/**
-			 * Get the executing CPU for this thread
-			 */
-			Affinity::Location affinity() { return Affinity::Location(); }
-
-			/**
-			 * Get thread name
-			 */
-			const char *name() const { return "noname"; }
-
-
-			/***********************
-			 ** Codezero specific **
-			 ***********************/
-
-			addr_t utcb() const { return _utcb; }
-
-			/**
-			 * Set CPU quota of the thread to 'quota'
-			 */
-			void quota(size_t const quota) { /* not supported*/ }
-	};
-}
-
-#endif /* _CORE__INCLUDE__PLATFORM_THREAD_H_ */

repos/base-codezero/src/core/include/util.h

@@ -1,46 +0,0 @@
-/*
- * \brief   Core-internal utilities
- * \author  Norman Feske
- * \date    2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _CORE__INCLUDE__UTIL_H_
-#define _CORE__INCLUDE__UTIL_H_
-
-/* Genode includes */
-#include <rm_session/rm_session.h>
-#include <base/printf.h>
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-namespace Genode {
-
-	constexpr size_t get_page_size_log2() { return 12; }
-	constexpr size_t get_page_size()      { return 1 << get_page_size_log2(); }
-	constexpr addr_t get_page_mask()      { return ~(get_page_size() - 1); }
-	inline addr_t trunc_page(addr_t addr) { return addr & get_page_mask(); }
-	inline addr_t round_page(addr_t addr) { return trunc_page(addr + get_page_size() - 1); }
-
-	inline addr_t map_src_addr(addr_t core_local, addr_t phys) { return phys; }
-	inline size_t constrain_map_size_log2(size_t size_log2) { return get_page_size_log2(); }
-
-	inline void print_page_fault(const char *msg, addr_t pf_addr, addr_t pf_ip,
-	                             Rm_session::Fault_type pf_type,
-	                             unsigned long faulter_badge)
-	{
-		printf("%s (%s pf_addr=%p pf_ip=%p from %02lx)\n", msg,
-		       pf_type == Rm_session::WRITE_FAULT ? "WRITE" : "READ",
-		       (void *)pf_addr, (void *)pf_ip,
-		       faulter_badge);
-	}
-}
-
-#endif /* _CORE__INCLUDE__UTIL_H_ */

repos/base-codezero/src/core/io_mem_session_support.cc

@@ -1,27 +0,0 @@
-/*
- * \brief  Implementation of the IO_MEM session interface
- * \author Norman Feske
- * \date   2009-03-29
- *
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* core includes */
-#include <io_mem_session_component.h>
-
-
-using namespace Genode;
-
-
-void Io_mem_session_component::_unmap_local(addr_t base, size_t size)
-{ }
-
-
-addr_t Io_mem_session_component::_map_local(addr_t base, size_t size)
-{ return 0; }

repos/base-codezero/src/core/irq_session_component.cc

@@ -1,134 +0,0 @@
-/*
- * \brief  Implementation of IRQ session component
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/printf.h>
-
-/* core includes */
-#include <irq_root.h>
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-
-using namespace Genode;
-
-
-bool Irq_object::_associate() { return true; }
-
-
-void Irq_object::_wait_for_irq()
-{
-	using namespace Codezero;
-
-	/* block for IRQ */
-	int ret = l4_irq_control(IRQ_CONTROL_WAIT, 0, _irq);
-	if (ret < 0)
-		PWRN("l4_irq_control(IRQ_CONTROL_WAIT) returned %d", ret);
-}
-
-
-void Irq_object::start()
-{
-	::Thread_base::start();
-	_sync_bootup.lock();
-}
-
-
-void Irq_object::entry()
-{
-	if (!_associate()) {
-		PERR("Could not associate with IRQ 0x%x", _irq);
-		return;
-	}
-
-	/* thread is up and ready */
-	_sync_bootup.unlock();
-
-	/* wait for first ack_irq */
-	_sync_ack.lock();
-
-	using namespace Codezero;
-
-	/* attach thread to IRQ when first called */
-	int ret = l4_irq_control(IRQ_CONTROL_REGISTER, 0, _irq);
-	if (ret < 0) {
-		PERR("l4_irq_control(IRQ_CONTROL_REGISTER) returned %d", ret);
-		return;
-	}
-
-	while (true) {
-
-		_wait_for_irq();
-
-		if (!_sig_cap.valid())
-			continue;
-
-		Genode::Signal_transmitter(_sig_cap).submit(1);
-
-		_sync_ack.lock();
-	}
-}
-
-
-Irq_object::Irq_object(unsigned irq)
-:
-	Thread<4096>("irq"),
-	_sync_ack(Lock::LOCKED), _sync_bootup(Lock::LOCKED),
-	_irq(irq)
-{ }
-
-
-Irq_session_component::Irq_session_component(Range_allocator *irq_alloc,
-                                             const char      *args)
-:
-	_irq_number(Arg_string::find_arg(args, "irq_number").long_value(-1)),
-	_irq_alloc(irq_alloc),
-	_irq_object(_irq_number)
-{
-	long msi = Arg_string::find_arg(args, "device_config_phys").long_value(0);
-	if (msi)
-		throw Root::Unavailable();
-
-	if (!irq_alloc || irq_alloc->alloc_addr(1, _irq_number).is_error()) {
-		PERR("Unavailable IRQ 0x%x requested", _irq_number);
-		throw Root::Unavailable();
-	}
-
-	_irq_object.start();
-}
-
-
-Irq_session_component::~Irq_session_component()
-{
-	PERR("Not yet implemented.");
-}
-
-
-void Irq_session_component::ack_irq()
-{
-	_irq_object.ack_irq();
-}
-
-
-void Irq_session_component::sigh(Genode::Signal_context_capability cap)
-{
-	_irq_object.sigh(cap);
-}
-
-
-Genode::Irq_session::Info Irq_session_component::info()
-{
-	/* no MSI support */
-	return { .type = Genode::Irq_session::Info::Type::INVALID };
-}

repos/base-codezero/src/core/platform.cc

@@ -1,302 +0,0 @@
-/*
- * \brief   Platform interface implementation
- * \author  Norman Feske
- * \date    2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/printf.h>
-#include <base/sleep.h>
-#include <base/thread.h>
-
-/* core includes */
-#include <core_parent.h>
-#include <platform.h>
-#include <map_local.h>
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-using namespace Genode;
-
-enum { verbose_boot_info = true };
-
-/*
- * Memory-layout information provided by the linker script
- */
-
-/* virtual address range consumed by core's program image */
-extern unsigned _prog_img_beg, _prog_img_end;
-
-/* physical address range occupied by core */
-extern addr_t _vma_start, _lma_start;
-
-
-/**************************
- ** Boot-module handling **
- **************************/
-
-/**
- * Scan ROM module image for boot modules
- *
- * By convention, the boot modules start at the page after core's BSS segment.
- */
-int Platform::_init_rom_fs()
-{
-	/**
-	 * Format of module meta-data as found in the ROM module image
-	 */
-	struct Module
-	{
-		long name;  /* physical address of null-terminated string */
-		long base;  /* physical address of module data */
-		long size;  /* size of module data in bytes */
-	};
-
-	/* find base address of ROM module image */
-	addr_t phys_base = round_page((addr_t)&_prog_img_end);
-
-	/* map the first page of the image containing the module meta data */
-	class Out_of_virtual_memory_during_rom_fs_init { };
-	void *virt_base = 0;
-	if (!_core_mem_alloc.virt_alloc()->alloc(get_page_size(), &virt_base))
-		throw Out_of_virtual_memory_during_rom_fs_init();
-
-	if (!map_local(phys_base, (addr_t)virt_base, 1)) {
-		PERR("map_local failed");
-		return -1;
-	}
-
-	/* remove page containing module infos from physical memory allocator */
-	_core_mem_alloc.phys_alloc()->remove_range(phys_base, get_page_size());
-
-	/* validate the presence of a ROM image by checking the magic cookie */
-	const char cookie[4] = {'G', 'R', 'O', 'M'};
-	for (size_t i = 0; i < sizeof(cookie); i++)
-		if (cookie[i] != ((char *)virt_base)[i]) {
-			PERR("could not detect ROM modules");
-			return -2;
-		}
-
-	printf("detected ROM module image at 0x%p\n", (void *)phys_base);
-
-	/* detect overly large meta data, we only support 4K */
-	addr_t end_of_header = ((long *)virt_base)[1];
-	size_t header_size = end_of_header - (long)phys_base;
-	if (header_size > get_page_size()) {
-		PERR("ROM fs module header exceeds %d bytes", get_page_size());
-		return -3;
-	}
-
-	/* start of module list */
-	Module *module = (Module *)((addr_t)virt_base + 2*sizeof(long));
-
-	/*
-	 * Interate over module list and populate core's ROM file system with
-	 * 'Rom_module' objects.
-	 */
-	for (; module->name; module++) {
-
-		/* convert physical address of module name to core-local address */
-		char *name = (char *)(module->name - phys_base + (addr_t)virt_base);
-
-		printf("ROM module \"%s\" at physical address 0x%p, size=%zd\n",
-		       name, (void *)module->base, (size_t)module->size);
-
-		Rom_module *rom_module = new (core_mem_alloc())
-			Rom_module(module->base, module->size, name);
-
-		_rom_fs.insert(rom_module);
-
-		/* remove module from physical memory allocator */
-		_core_mem_alloc.phys_alloc()->remove_range(module->base, round_page(module->size));
-	}
-	return 0;
-}
-
-
-/****************************************
- ** Support for core memory management **
- ****************************************/
-
-bool Core_mem_allocator::Mapped_mem_allocator::_map_local(addr_t virt_addr,
-                                                          addr_t phys_addr,
-                                                          unsigned size)
-{
-	return map_local(phys_addr, virt_addr, size / get_page_size());
-}
-
-
-bool Core_mem_allocator::Mapped_mem_allocator::_unmap_local(addr_t virt_addr,
-                                                            unsigned size)
-{
-	return unmap_local(virt_addr, size / get_page_size());
-}
-
-
-/************************
- ** Platform interface **
- ************************/
-
-Platform::Platform() :
-	_io_mem_alloc(core_mem_alloc()), _io_port_alloc(core_mem_alloc()),
-	_irq_alloc(core_mem_alloc()), _vm_base(0), _vm_size(0)
-{
-	using namespace Codezero;
-
-	/* init core UTCB */
-	static char main_utcb[PAGE_SIZE] __attribute__((aligned(PAGE_SIZE)));
-	static struct exregs_data exregs;
-	exregs_set_utcb(&exregs, (unsigned long)&main_utcb[0]);
-	l4_exchange_registers(&exregs, thread_myself());
-
-	/* error handling is futile at this point */
-
-	/* read number of capabilities */
-	int num_caps;
-	int ret;
-	if ((ret = l4_capability_control(CAP_CONTROL_NCAPS,
-	                                 0, &num_caps)) < 0) {
-		PERR("l4_capability_control(CAP_CONTROL_NCAPS) returned %d", ret);
-		class Could_not_obtain_num_of_capabilities { };
-		throw Could_not_obtain_num_of_capabilities();
-	}
-
-	struct capability cap_array[num_caps];
-
-	if (verbose_boot_info)
-		printf("allocated cap array[%d] of size %d on stack\n",
-		       num_caps, sizeof(cap_array));
-
-	/* read all capabilities */
-	if ((ret = l4_capability_control(CAP_CONTROL_READ,
-	                                 0, cap_array)) < 0) {
-		PERR("l4_capability_control(CAP_CONTROL_READ) returned %d", ret);
-		class Read_caps_failed { };
-		throw Read_caps_failed();
-	}
-
-	/* initialize core allocators */
-	bool phys_mem_defined = false;
-	addr_t dev_mem_base = 0;
-	for (int i = 0; i < num_caps; i++) {
-		struct capability *cap = &cap_array[i];
-
-		addr_t base = cap->start << get_page_size_log2(),
-		       size = cap->size  << get_page_size_log2();
-
-		if (verbose_boot_info)
-			printf("cap type=%x, rtype=%x, base=%lx, size=%lx\n",
-			       cap_type(cap), cap_rtype(cap), base, size);
-
-		switch (cap_type(cap)) {
-
-		case CAP_TYPE_MAP_VIRTMEM:
-
-			/*
-			 * Use first non-UTCB virtual address range as default
-			 * virtual memory range usable for all processes.
-			 */
-			if (_vm_size == 0) {
-
-				/* exclude page at virtual address 0 */
-				if (base == 0 && size >= get_page_size()) {
-					base += get_page_size();
-					size -= get_page_size();
-				}
-
-				_vm_base = base;
-				_vm_size = size;
-
-				/* add range as free range to core's virtual address allocator */
-				_core_mem_alloc.virt_alloc()->add_range(base, size);
-				break;
-			}
-
-			PWRN("ignoring additional virtual address range [%lx,%lx)",
-			     base, base + size);
-			break;
-
-		case CAP_TYPE_MAP_PHYSMEM:
-
-			/*
-			 * We interpret the first physical memory resource that is bigger
-			 * than typical device resources as RAM.
-			 */
-			enum { RAM_SIZE_MIN = 16*1024*1024 };
-			if (!phys_mem_defined && size > RAM_SIZE_MIN) {
-				_core_mem_alloc.phys_alloc()->add_range(base, size);
-				phys_mem_defined = true;
-				dev_mem_base = base + size;
-			}
-			break;
-
-		case CAP_TYPE_IPC:
-		case CAP_TYPE_UMUTEX:
-		case CAP_TYPE_IRQCTRL:
-		case CAP_TYPE_QUANTITY:
-			break;
-		}
-	}
-
-	addr_t core_virt_beg = trunc_page((addr_t)&_prog_img_beg),
-	       core_virt_end = round_page((addr_t)&_prog_img_end);
-	size_t core_size     = core_virt_end - core_virt_beg;
-
-	printf("core image:\n");
-	printf("  virtual address range [%08lx,%08lx) size=0x%zx\n",
-	       core_virt_beg, core_virt_end, core_size);
-	printf("  physically located at 0x%08lx\n", _lma_start);
-
-	/* remove core image from core's virtual address allocator */
-	_core_mem_alloc.virt_alloc()->remove_range(core_virt_beg, core_size);
-
-	/* preserve context area in core's virtual address space */
-	_core_mem_alloc.virt_alloc()->raw()->remove_range(Native_config::context_area_virtual_base(),
-	                                                  Native_config::context_area_virtual_size());
-
-	/* remove used core memory from physical memory allocator */
-	_core_mem_alloc.phys_alloc()->remove_range(_lma_start, core_size);
-
-	/* remove magically mapped UART from core virtual memory */
-	_core_mem_alloc.virt_alloc()->remove_range(USERSPACE_CONSOLE_VBASE, get_page_size());
-
-	/* add boot modules to ROM fs */
-	if (_init_rom_fs() < 0) {
-		PERR("initialization of romfs failed - halt.");
-		while(1);
-	}
-
-	/* initialize interrupt allocator */
-	_irq_alloc.add_range(0, 255);
-
-	/* regard physical addresses higher than memory area as MMIO */
-	_io_mem_alloc.add_range(dev_mem_base, 0x80000000 - dev_mem_base);
-
-	/*
-	 * Print statistics about allocator initialization
-	 */
-	printf("VM area at [%08lx,%08lx)\n", _vm_base, _vm_base + _vm_size);
-
-	if (verbose_boot_info) {
-		printf(":phys_alloc:   "); _core_mem_alloc.phys_alloc()->raw()->dump_addr_tree();
-		printf(":virt_alloc:   "); _core_mem_alloc.virt_alloc()->raw()->dump_addr_tree();
-		printf(":io_mem_alloc: "); _io_mem_alloc.raw()->dump_addr_tree();
-	}
-}
-
-
-void Platform::wait_for_exit()
-{
-	sleep_forever();
-}
-
-
-void Core_parent::exit(int exit_value) { }

repos/base-codezero/src/core/platform_pd.cc

@@ -1,127 +0,0 @@
-/*
- * \brief   Protection-domain facility
- * \author  Norman Feske
- * \date    2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/printf.h>
-
-/* core includes */
-#include <platform_pd.h>
-#include <platform.h>
-#include <util.h>
-
-using namespace Genode;
-using namespace Codezero;
-
-
-/***************************
- ** Public object members **
- ***************************/
-
-int Platform_pd::bind_thread(Platform_thread *thread)
-{
-	/* allocate new thread at the kernel */
-	struct task_ids ids = { 1, _space_id, TASK_ID_INVALID };
-	int ret = l4_thread_control(THREAD_CREATE | TC_SHARE_SPACE, &ids);
-	if (ret < 0) {
-		PERR("l4_thread_control returned %d, tid=%d\n", ret, ids.tid);
-		return -1;
-	}
-
-	/* allocate UTCB for new thread */
-	int utcb_idx;
-	for (utcb_idx = 0; utcb_idx < MAX_THREADS_PER_PD; utcb_idx++)
-		if (!utcb_in_use[utcb_idx]) break;
-
-	if (utcb_idx == MAX_THREADS_PER_PD) {
-		PERR("UTCB allocation failed");
-		return -2;
-	}
-
-	/* mark UTCB as being in use */
-	utcb_in_use[utcb_idx] = true;
-
-	/* map UTCB area for the first thread of a new PD */
-	if (utcb_idx == 0) {
-		void *utcb_phys = 0;
-		if (!platform()->ram_alloc()->alloc(UTCB_AREA_SIZE, &utcb_phys)) {
-			PERR("could not allocate physical pages for UTCB");
-			return -3;
-		}
-
-		ret = l4_map(utcb_phys, (void *)UTCB_VIRT_BASE,
-		             UTCB_AREA_SIZE/get_page_size(), MAP_USR_RW, ids.tid);
-		if (ret < 0) {
-			PERR("UTCB mapping into new PD failed, ret=%d", ret);
-			return -4;
-		}
-	}
-
-	addr_t utcb_addr = UTCB_VIRT_BASE + utcb_idx*sizeof(struct utcb);
-	thread->_assign_physical_thread(ids.tid, _space_id, utcb_addr,
-	                                this->Address_space::weak_ptr());
-	return 0;
-}
-
-
-void Platform_pd::unbind_thread(Platform_thread *thread)
-{
-	/* find UTCB index of thread */
-	unsigned utcb_idx;
-	for (utcb_idx = 0; utcb_idx < MAX_THREADS_PER_PD; utcb_idx++)
-		if (thread->utcb() == UTCB_VIRT_BASE + utcb_idx*sizeof(struct utcb))
-			break;
-
-	if (utcb_idx == MAX_THREADS_PER_PD) {
-		PWRN("could not find UTCB index of thread");
-		return;
-	}
-
-	utcb_in_use[utcb_idx] = false;
-
-	PWRN("not fully implemented");
-}
-
-
-Platform_pd::Platform_pd(bool core)
-{
-	PWRN("not yet implemented");
-}
-
-
-Platform_pd::Platform_pd(Allocator * md_alloc, char const *,
-                         signed pd_id, bool create)
-: _space_id(TASK_ID_INVALID)
-{
-	_space_id = TASK_ID_INVALID;
-
-	/* mark all UTCBs of the new PD as free */
-	for (int i = 0; i < MAX_THREADS_PER_PD; i++)
-		utcb_in_use[i] = false;
-
-	struct task_ids ids = { TASK_ID_INVALID, TASK_ID_INVALID, TASK_ID_INVALID };
-
-	int ret = l4_thread_control(THREAD_CREATE | TC_NEW_SPACE, &ids);
-	if (ret < 0) {
-		PERR("l4_thread_control(THREAD_CREATE | TC_NEW_SPACE) returned %d", ret);
-		return;
-	}
-
-	/* set space ID to valid value to indicate success */
-	_space_id = ids.spid;
-}
-
-
-Platform_pd::~Platform_pd()
-{
-	PWRN("not yet implemented");
-}

repos/base-codezero/src/core/platform_thread.cc

@@ -1,112 +0,0 @@
-/*
- * \brief   Thread facility
- * \author  Norman Feske
- * \date    2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/printf.h>
-#include <util/string.h>
-
-/* core includes */
-#include <platform_thread.h>
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-enum { verbose_thread_start = true };
-
-using namespace Genode;
-using namespace Codezero;
-
-
-int Platform_thread::start(void *ip, void *sp, unsigned int cpu_no)
-{
-	Native_thread_id pager = _pager ? _pager->cap().dst() : THREAD_INVALID;
-
-	/* setup thread context */
-	struct exregs_data exregs;
-	memset(&exregs, 0, sizeof(exregs));
-	exregs_set_stack(&exregs, (unsigned long)sp);
-	exregs_set_pc   (&exregs, (unsigned long)ip);
-	exregs_set_pager(&exregs, pager);
-	exregs_set_utcb (&exregs, _utcb);
-
-	int ret = l4_exchange_registers(&exregs, _tid);
-	if (ret < 0) {
-		printf("l4_exchange_registers returned ret=%d\n", ret);
-		return -2;
-	}
-
-	/* start execution */
-	struct task_ids ids = { _tid, _space_id, _tid };
-	ret = l4_thread_control(THREAD_RUN, &ids);
-	if (ret < 0) {
-		printf("Error: l4_thread_control(THREAD_RUN) returned %d\n", ret);
-		return -3;
-	}
-
-	if (verbose_thread_start)
-		printf("core started thread \"%s\" with ID %d inside space ID %d\n",
-		       _name, _tid, _space_id);
-	return 0;
-}
-
-
-void Platform_thread::pause()
-{
-	PDBG("not implemented");
-}
-
-
-void Platform_thread::resume()
-{
-	PDBG("not implemented");
-}
-
-
-void Platform_thread::state(Thread_state s)
-{
-	PDBG("Not implemented");
-	throw Cpu_session::State_access_failed();
-}
-
-
-Thread_state Platform_thread::state()
-{
-	PDBG("Not implemented");
-	throw Cpu_session::State_access_failed();
-}
-
-
-void Platform_thread::cancel_blocking()
-{
-	PDBG("not implemented");
-}
-
-
-Weak_ptr<Address_space> Platform_thread::address_space()
-{
-	return _address_space;
-}
-
-
-Platform_thread::Platform_thread(size_t, const char *name, unsigned, addr_t,
-                                 int thread_id)
-: _tid(THREAD_INVALID)
-{
-	strncpy(_name, name, sizeof(_name));
-}
-
-
-Platform_thread::~Platform_thread()
-{
-	PDBG("not implemented");
-}

repos/base-codezero/src/core/ram_session_support.cc

@@ -1,65 +0,0 @@
-/*
- * \brief  Export RAM dataspace as shared memory object (dummy)
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Genode includes */
-#include <base/printf.h>
-#include <util/misc_math.h>
-
-/* core includes */
-#include <ram_session_component.h>
-#include <platform.h>
-#include <map_local.h>
-
-
-using namespace Genode;
-
-void Ram_session_component::_export_ram_ds(Dataspace_component *ds) { }
-void Ram_session_component::_revoke_ram_ds(Dataspace_component *ds) { }
-
-void Ram_session_component::_clear_ds (Dataspace_component *ds)
-{
-	using namespace Codezero;
-
-	/*
-	 * Map dataspace core-locally, memset, unmap dataspace
-	 */
-
-	size_t page_rounded_size = (ds->size() + get_page_size() - 1) & get_page_mask();
-	size_t num_pages         = page_rounded_size >> get_page_size_log2();
-
-	/* allocate range in core's virtual address space */
-	void *virt_addr;
-	if (!platform()->region_alloc()->alloc(page_rounded_size, &virt_addr)) {
-		PERR("Could not allocate virtual address range in core of size %zd\n",
-		     page_rounded_size);
-		return;
-	}
-
-	/* map the dataspace's physical pages to corresponding virtual addresses */
-	if (!map_local(ds->phys_addr(), (addr_t)virt_addr, num_pages)) {
-		PERR("core-local memory mapping failed\n");
-		return;
-	}
-
-	memset(virt_addr, 0, ds->size());
-
-	/* unmap dataspace from core */
-	if (!unmap_local((addr_t)virt_addr, num_pages)) {
-		PERR("could not unmap %zd pages from virtual address range at %p",
-		     num_pages, virt_addr);
-		return;
-	}
-
-	/* free core's virtual address space */
-	platform()->region_alloc()->free(virt_addr, page_rounded_size);
-}

repos/base-codezero/src/core/rm_session_support.cc

@@ -1,28 +0,0 @@
-/*
- * \brief  RM-session implementation
- * \author Norman Feske
- * \date   2009-10-02
- */
-
-/*
- * Copyright (C) 2009-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* core includes */
-#include <rm_session_component.h>
-#include <util.h>
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-using namespace Genode;
-using namespace Codezero;
-
-
-void Rm_client::unmap(addr_t core_local_base, addr_t virt_base, size_t size)
-{
-	l4_unmap((void *)virt_base, size >> get_page_size_log2(), badge());
-}

repos/base-codezero/src/core/target.inc

@@ -1,59 +0,0 @@
-TARGET       = core
-
-GEN_CORE_DIR = $(BASE_DIR)/src/core
-
-SRC_CC      += \
-               main.cc \
-               ram_session_component.cc \
-               ram_session_support.cc \
-               rom_session_component.cc \
-               cap_session_component.cc \
-               cpu_session_component.cc \
-               cpu_session_support.cc \
-               pd_session_component.cc \
-               io_mem_session_component.cc \
-               io_mem_session_support.cc \
-               thread_start.cc \
-               platform_thread.cc \
-               platform_pd.cc \
-               platform_services.cc \
-               platform.cc \
-               dataspace_component.cc \
-               rm_session_component.cc \
-               rm_session_support.cc \
-               irq_session_component.cc \
-               signal_session_component.cc \
-               signal_source_component.cc \
-               trace_session_component.cc \
-               core_rm_session.cc \
-               core_mem_alloc.cc \
-               dump_alloc.cc \
-               context_area.cc
-
-LIBS        += core_printf base-common
-
-INC_DIR     += $(REP_DIR)/src/core/include \
-               $(GEN_CORE_DIR)/include \
-               $(REP_DIR)/include/codezero/dummies \
-               $(BASE_DIR)/src/base/thread
-
-include $(GEN_CORE_DIR)/version.inc
-
-vpath main.cc                     $(GEN_CORE_DIR)
-vpath ram_session_component.cc    $(GEN_CORE_DIR)
-vpath rom_session_component.cc    $(GEN_CORE_DIR)
-vpath cap_session_component.cc    $(GEN_CORE_DIR)
-vpath cpu_session_component.cc    $(GEN_CORE_DIR)
-vpath pd_session_component.cc     $(GEN_CORE_DIR)
-vpath rm_session_component.cc     $(GEN_CORE_DIR)
-vpath io_mem_session_component.cc $(GEN_CORE_DIR)
-vpath io_mem_session_support.cc   $(GEN_CORE_DIR)
-vpath platform_services.cc        $(GEN_CORE_DIR)
-vpath signal_session_component.cc $(GEN_CORE_DIR)
-vpath signal_source_component.cc  $(GEN_CORE_DIR)
-vpath trace_session_component.cc  $(GEN_CORE_DIR)
-vpath dataspace_component.cc      $(GEN_CORE_DIR)
-vpath core_mem_alloc.cc           $(GEN_CORE_DIR)
-vpath dump_alloc.cc               $(GEN_CORE_DIR)
-vpath context_area.cc             $(GEN_CORE_DIR)
-vpath %.cc                        $(REP_DIR)/src/core

repos/base-codezero/src/core/target.mk

@@ -1,4 +0,0 @@
-include $(PRG_DIR)/target.inc
-
-LD_TEXT_ADDR = 0x100000
-

repos/base-codezero/src/core/thread_start.cc

@@ -1,121 +0,0 @@
-/*
- * \brief  Implementation of Thread API interface for core
- * \author Norman Feske
- * \date   2006-05-03
- */
-
-/*
- * Copyright (C) 2006-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* Codezero includes */
-#include <codezero/syscalls.h>
-
-/* Genode includes */
-#include <base/thread.h>
-#include <base/printf.h>
-#include <base/sleep.h>
-
-/* core includes */
-#include <platform.h>
-#include <platform_thread.h>
-
-enum { verbose_thread_start = true };
-
-using namespace Genode;
-
-void Thread_base::_deinit_platform_thread() { }
-
-
-/**
- * Create and start new thread
- *
- * \param space_no   space ID in which the new thread will be executed
- * \param sp         initial stack pointer
- * \param ip         initial instruction pointer
- * \return           new thread ID, or
- *                   negative error code
- */
-inline int create_thread(unsigned space_no,
-                         void *sp, void *ip,
-                         int pager_tid = 1)
-{
-	using namespace Codezero;
-
-	struct task_ids ids = { 1U, space_no, TASK_ID_INVALID };
-
-	/* allocate new thread at the kernel */
-	unsigned long flags = THREAD_CREATE | TC_SHARE_SPACE | TC_SHARE_GROUP;
-	int ret = l4_thread_control(flags, &ids);
-	if (ret < 0) {
-		PERR("l4_thread_control returned %d, spid=%d\n",
-		     ret, ids.spid);
-		return -1;
-	}
-
-	unsigned long utcb_base_addr = (unsigned long)l4_get_utcb();
-
-	/* calculate utcb address of new thread */
-	unsigned long new_utcb = utcb_base_addr + ids.tid*sizeof(struct utcb);
-
-	/* setup thread context */
-	struct exregs_data exregs;
-	memset(&exregs, 0, sizeof(exregs));
-	exregs_set_stack(&exregs, (unsigned long)sp);
-	exregs_set_pc   (&exregs, (unsigned long)ip);
-	exregs_set_pager(&exregs, pager_tid);
-	exregs_set_utcb (&exregs, new_utcb);
-
-	ret = l4_exchange_registers(&exregs, ids.tid);
-	if (ret < 0) {
-		printf("l4_exchange_registers returned ret=%d\n", ret);
-		return -2;
-	}
-
-	/* start execution */
-	ret = l4_thread_control(THREAD_RUN, &ids);
-	if (ret < 0) {
-		printf("Error: l4_thread_control(THREAD_RUN) returned %d\n", ret);
-		return -3;
-	}
-
-	/* return new thread ID allocated by the kernel */
-	return ids.tid;
-}
-
-
-void Thread_base::_thread_start()
-{
-	Thread_base::myself()->_thread_bootstrap();
-	Thread_base::myself()->entry();
-	sleep_forever();
-}
-
-
-void Thread_base::start()
-{
-	/* create and start platform thread */
-	_tid.pt = new(platform()->core_mem_alloc())
-		Platform_thread(0, _context->name);
-
-	_tid.l4id = create_thread(1, stack_top(), (void *)&_thread_start);
-
-	if (_tid.l4id < 0)
-		PERR("create_thread returned %d", _tid.l4id);
-
-	if (verbose_thread_start)
-		printf("core started local thread \"%s\" with ID %d\n",
-		       _context->name, _tid.l4id);
-
-}
-
-
-void Thread_base::cancel_blocking()
-{
-	PWRN("not implemented");
-}
-
-

repos/base-codezero/src/kernel/target.mk

@@ -1,71 +0,0 @@
-TARGET = codezero
-
-CODEZERO_DIR := $(call select_from_ports,codezero)/src/kernel/codezero
-
-include $(REP_DIR)/lib/mk/codezero_cml.inc
-
-TOOL_CHAIN_DIR     = $(dir $(CROSS_DEV_PREFIX))
-CODEZERO_DST_DIR   = $(BUILD_BASE_DIR)/kernel/codezero
-CODEZERO_BUILD_DIR = $(CODEZERO_DST_DIR)/build
-
-.PHONY: $(TARGET)
-
-MIRROR_COPY := conts/baremetal/empty conts/userlibs \
-               build.py include SConstruct src loader
-
-MIRROR_SYMLINK := scripts tools
-
-update_copy = $(VERBOSE)tar c -C $(CODEZERO_DIR) $(MIRROR_COPY) | tar x -C $(CODEZERO_DST_DIR)
-
-ifneq ($(VERBOSE),)
-CODEZERO_STDOUT := > /dev/null
-endif
-
-#
-# Environment variables passed to the Codezero build system
-#
-BUILD_ENV = PATH=$(dir $(CROSS_DEV_PREFIX)):$$PATH
-
-#
-# Local copy of the CML file used for supplying the configuration
-# to the Codezero build system.
-#
-LOCAL_CONFIG_CML := $(shell pwd)/config.cml
-
-$(TARGET): $(CODEZERO_BUILD_DIR)
-	$(MSG_BUILD)kernel
-	$(update_copy)
-	$(VERBOSE)cd $(CODEZERO_DST_DIR); $(BUILD_ENV) ./build.py $(CODEZERO_STDOUT)
-
-#
-# Mirror the parts of the Codezero source tree that are relevant for building
-# the kernel
-#
-$(CODEZERO_DST_DIR): $(CODEZERO_DIR)
-	$(VERBOSE)test -d $@ || mkdir -p $@
-	$(VERBOSE)for d in $(MIRROR_SYMLINK); do ln -sf $(realpath $^)/$$d $@/$$d; done
-
-$(CODEZERO_BUILD_DIR): $(CODEZERO_DST_DIR) $(CODEZERO_CML)
-	$(update_copy)
-	$(VERBOSE)cp $(CODEZERO_CML) $(LOCAL_CONFIG_CML)
-	@#
-	@# Create copy of the CML config in the local build directory to update
-	@# the tool chain parameters according to the CROSS_DEV_PREFIX configured
-	@# for Genode.
-	@#
-	$(VERBOSE)sed -i "/TOOLCHAIN_USERSPACE/s/\".*\"/\"$(notdir $(CROSS_DEV_PREFIX))\"/" $(LOCAL_CONFIG_CML)
-	$(VERBOSE)sed -i "/TOOLCHAIN_KERNEL/s/\".*\"/\"$(notdir $(CROSS_DEV_PREFIX))\"/" $(LOCAL_CONFIG_CML)
-	$(VERBOSE)cd $(CODEZERO_DST_DIR); $(BUILD_ENV) ./build.py -C -b -f $(LOCAL_CONFIG_CML) $(CODEZERO_STDOUT)
-
-clean cleanall: clean_codezero
-
-#
-# Make sure to execute the 'clean_codezero' rule prior the generic clean
-# rule in 'prg.mk' because the generic rule will attempt to remove $(TARGET)
-# file, which is a directory in our case.
-#
-clean_prg_objects: clean_codezero
-
-clean_codezero:
-	$(VERBOSE)rm -f  $(LOCAL_CONFIG_CML)
-	$(VERBOSE)rm -rf $(CODEZERO_DST_DIR)

repos/base-codezero/src/lib/syscall/dummy.c

@@ -1,22 +0,0 @@
-/*
- * \brief  Dummies for Codezeros libmem (used by libl4)
- * \author Sebastian Sumpf
- * \date   2011-05-10
- */
-
-/*
- * Copyright (C) 2011-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-void *mem_cache_zalloc(void *cache){ return 0; }
-void *mem_cache_alloc(void *cache){ return 0; }
-void *mem_cache_init(void *start, int cache_size, int struct_size,
-                     unsigned int alignment) { return 0; }
-int mem_cache_free(void *cache, void *addr) { return 0; }
-
-void *kmalloc(int size) { return 0; }
-
-

repos/base-codezero/src/platform/genode.ld

@@ -1,131 +0,0 @@
-/*
- * \brief  Linker script for Genode programs
- * \author Christian Helmuth
- * \date   2006-04-12
- */
-
-/*
- * Copyright (C) 2006-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-/* values taken from Codezero's mm0 linker script */
-/*physical_base = 0x00208000;*/
-/*virtual_base  = 0xe0000000;*/
-/*offset        = virtual_base - physical_base;*/
-
-/*
- * Addresses correspond to the linker script generated by
- * the Codezero build system.
- */
-vma_start = 0x100000;
-lma_start = 0x41000;
-offset = vma_start - lma_start;
-
-
-ENTRY(_start)
-
-PHDRS
-{
-  ro PT_LOAD;
-  rw PT_LOAD;
-}
-
-SECTIONS
-{
-	. = vma_start;
-
-	.text : AT (ADDR(.text) - offset) {
-		/* begin of program image (link address) */
-		_prog_img_beg = .;
-
-		*(.text.crt0)
-		*(.init)
-		*(.text .text.* .gnu.linkonce.t.*)
-		*(.fini)
-		*(.rodata .rodata.* .gnu.linkonce.r.*)
-
-		. = ALIGN(0x08);
-
-		_ctors_start = .;
-		KEEP (*(.ctors))
-		KEEP (*(SORT(.ctors.*)))
-		KEEP (*(.init_array)) /* list of constructors specific for ARM eabi */
-		_ctors_end = .;
-		_dtors_start = .;
-		KEEP (*(SORT(.dtors.*)))
-		KEEP (*(.dtors))
-		_dtors_end = .;
-	} : ro = 0x0
-
-	/* Linux: exception section for uaccess mechanism */
-	__ex_table : { *(__ex_table) }
-
-	.eh_frame_hdr : { *(.eh_frame_hdr) }
-
-	. = ALIGN(0x1000);
-
-	_prog_img_data = .;
-
-	.data : AT (ADDR(.data) - offset) {
-		/*
-		 * Leave space for parent capability parameters at start of data
-		 * section. The protection domain creator is reponsible for storing
-		 * sane values here.
-		 */
-		_parent_cap = .;
-		LONG(0xffffffff);
-		LONG(0xffffffff);
-		_vma_start = .;
-		LONG(vma_start);
-		_lma_start = .;
-		LONG(lma_start);
-
-		*(.data .data.* .gnu.linkonce.d.*)
-	} : rw
-
-	/* exception frames for C++ */
-	.eh_frame : {
-		__eh_frame_start__ = .;
-		KEEP (*(.eh_frame))
-		LONG(0)
-	} : rw
-
-	.init_array : {
-		PROVIDE_HIDDEN (__init_array_start = .);
-		KEEP (*(SORT(.init_array.*)))
-		KEEP (*(.init_array))
-		PROVIDE_HIDDEN (__init_array_end = .);
-	}
-
-	.gcc_except_table : { KEEP(*(.gcc_except_table)) }
-	.dynamic :  { *(.dynamic) }
-
-	/* .ARM.exidx is sorted, so has to go in its own output section */
-	__exidx_start = .;
-	.ARM.exidx : {
-		*(.ARM.exidx* .gnu.linkonce.armexidx.*)
-	}
-	__exidx_end = .;
-
-	.ARM.extab : {
-		*(.ARM.extab*)
-	} : rw
-
-	. = ALIGN(4);
-
-	.bss : AT (ADDR(.bss) - offset) {
-		*(.bss .bss.* .gnu.linkonce.b.* COMMON)
-	}
-
-	/* end of program image -- must be after last section */
-	_prog_img_end = .;
-
-	/DISCARD/ : {
-		*(.note)
-		*(.note.ABI-tag)
-		*(.comment)
-	}
-}

repos/base-codezero/tool/gen_romfs

@@ -1,202 +0,0 @@
-#!/usr/bin/python
-
-import os, re, getopt, sys
-from stat import ST_SIZE
-from subprocess import PIPE, Popen
-
-verbose = 0
-
-
-# return address of 4K page following the spefified address
-def round_page(addr):
-	page_size = 0x1000
-	return (addr + page_size) & ~(page_size - 1)
-
-
-def first_free_addr_after_program(elf, cross_prefix = ""):
-	try:
-		objdump = cross_prefix + "objdump"
-		objdump_output = Popen([objdump, "-p", elf],
-		                       stdout=PIPE).communicate()[0]
-	except OSError:
-		print "Error: execution of " + objdump + " failed, invalid cross-tool prefix?"
-		exit(3)
-
-	#
-	# The output of 'objdump -p' contains the list of program segments. Each
-	# segment has two lines of text, the first containing the 'vaddr' value and
-	# the latter containing the 'memsz' value. For each line, we match for both
-	# 'vaddr' and 'memsz' fields. When observing a line with a 'memsz' field,
-	# we know that the previous line contained the corresponding 'vaddr' and
-	# that the end address of the segment is the sum of the current 'vaddr'
-	# and 'memsz' values.
-	#
-	max_end_addr = 0
-	for line in objdump_output.splitlines():
-		match_vaddr = re.compile(".*vaddr (0x[0-9a-f]*).*").match(line)
-		match_memsz = re.compile(".*memsz (0x[0-9a-f]*).*").match(line)
-		if (match_vaddr):
-			vaddr = int(match_vaddr.group(1), 0)
-		if (match_memsz):
-			memsz = int(match_memsz.group(1), 0)
-			max_end_addr = max(max_end_addr, vaddr + memsz)
-
-	# align the first free address at the next page boundary
-	return round_page(max_end_addr)
-
-
-def generate_modules_asm(modules):
-	"""
-	Generate assembly code aggregating boot-module data from specified files.
-	The generated assembly code looks as follows:
-
-	/*
-	 * The ELF image consists only of a data section. At file offset 0, there
-	 * is a magic cookie that core validates when accessing the ROM fs. It is
-	 * followed by the end address of the meta data.
-	 */
-	.section .data
-	.string "GROM"     /* magic cookie used by core to identify a ROM fs image*/
-	.long header_end   /* end of ROM fs meta data */
-
-	/*
-	 * Each module is represented by a struct of 3 long values. The first
-	 * value is pointer to the module name. A null-pointer marks the end of
-	 * the module list.
-	 */
-	.long mod1_name             /* pointer to the null-terminated module name */
-	.long mod1_start            /* pointer to the module data */
-	.long mod1_end - mod1_start /* size of the module data */
-
-	.long 0
-
-	/*
-	 * For each module, there exists a null-terminated string labeled with
-	 * 'mod<index>_name' referenced by the module list above.
-	 */
-	mod1_name:
-	.string "name of data module"
-	.byte 0
-
-	header_end:
-
-	/*
-	 * The data of each module must be aligned at a page boundary to enable
-	 * the mapping of individual modules to different address spaces.
-	 */
-	.align 4096
-	mod1_start: .incbin "data"
-	mod1_end:
-	"""
-
-	asm_src = ""
-
-	# header
-	asm_src += ".section .data\nmodule_list:\n"
-	asm_src += ".ascii \"GROM\"\n"
-	asm_src += ".long header_end\n"
-
-	# module list
-	i = 1
-	for module in modules:
-		asm_src += ".long mod" + str(i) + "_name\n"
-		asm_src += ".long mod" + str(i) + "_start\n"
-		asm_src += ".long mod" + str(i) + "_end - mod" + str(i) + "_start\n"
-		i = i + 1
-	asm_src += ".long 0\n"
-
-	# module names
-	i = 1
-	for module in modules:
-		asm_src += "mod" + str(i) + "_name: .string \"" + os.path.split(module)[1] + "\"; .byte 0\n"
-		i = i + 1
-
-	asm_src += "header_end:\n"
-
-	# module data
-	i = 1
-	for module in modules:
-		asm_src += ".p2align 12,0\n"
-		asm_src += "mod" + str(i) + "_start: .incbin \"" + module + "\"; "
-		asm_src += "mod" + str(i) + "_end:\n"
-		i = i + 1
-
-	return asm_src
-
-instructions = """
-usage: gen_romfs [-v] [-p <cross-prefix>] -c <core-elf> -o <output> [modules ...]
-
-Generates Genode ROM file system as ELF file loadable into a Codezero container
-
-  -c|--core     ELF binary of Genode's core
-  -o|--output   name of ELF image to generate
-  -p|--prefix   cross toolchain prefix
-  -v|--verbose  print details about generated ROM file systemn
-"""
-
-def usage():
-	print instructions
-
-def user_error(message):
-	print "Error: " + message
-	usage
-	sys.exit(2)
-
-# default values for command-line arguments
-cross_prefix = ""
-core_elf     = ""
-dst_elf      = ""
-
-# parse command line arguments
-try:
-	opts, modules = getopt.getopt(sys.argv[1:],
-	                              "c:o:p:v",
-	                              ["core=", "output=", "prefix=", "verbose"])
-except getopt.GetoptError:
-	usage()
-	sys.exit(2)
-for opt, arg in opts:
-	if opt in ("-c", "--core"):
-		core_elf = arg
-	elif opt in ("-o", "--output"):
-		dst_elf = arg
-	elif opt in ("-p", "--prefix"):
-		cross_prefix = arg
-	elif opt in ("-v", "--verbose"):
-		verbose = 1
-	else:
-		user_error("invalid argument \"" + arg + "\"")
-
-# validate arguments
-if (core_elf     == ""): user_error("no core binary specified")
-if (len(modules) ==  0): user_error("no modules specified")
-if (dst_elf      == ""): user_error("no output file spefied")
-
-# determine destination address of the modules ELF image
-modules_start_addr = first_free_addr_after_program(core_elf, cross_prefix)
-
-if (verbose):
-	print "module address: " + hex(modules_start_addr)
-
-# generate assembly code aggregating the module data
-asm_src = generate_modules_asm(modules)
-
-if (verbose):
-	print "generated assember code:"
-	for line in asm_src.splitlines():
-		print "  " + line
-
-# invoke assembler and linker through the gcc front end
-gcc_cmd = [cross_prefix + "gcc",
-           "-nostdlib",
-           "-x", "assembler",
-           "-Wl,--entry=0",
-           "-Wl,--section-start=.data="   + hex(modules_start_addr),
-           "-o", dst_elf,
-           "-"]
-
-if (verbose):
-	print "gcc command line:"
-	print "  " + ' '.join(gcc_cmd)
-
-Popen(gcc_cmd, stdin=PIPE).communicate(asm_src)[0]

repos/base-fiasco/Makefile

@@ -1 +0,0 @@
-include ../../tool/prepare.mk

repos/base-fiasco/doc/fiasco.txt

@@ -40,15 +40,14 @@ Information about Fiasco are provided at its official website:
 ! http://os.inf.tu-dresden.de/fiasco/prev/
 
 To download the kernel and integrate it with Genode, issue the following
-command from within the 'base-fiasco' directory:
+command from within the toplevel directory:
 
-! make prepare
+! ./tool/ports/prepare_port fiasco
 
 For the vesa driver on x86 the x86emu library is required and can be downloaded
-and prepared by invoking the following command from within the 'libports'
-directory:
+and prepared by invoking the following command:
 
-! make prepare PKG=x86emu
+! ./tool/ports/prepare_port x86emu
 
 This command will download a prepackaged version of the kernel tested
 with Genode. The build process of the kernel is integrated with Genode's

repos/base-fiasco/include/base/cancelable_lock.h

@@ -1,56 +0,0 @@
-/*
- * \brief  Basic locking primitive
- * \author Norman Feske
- * \date   2006-07-26
- */
-
-/*
- * Copyright (C) 2006-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _INCLUDE__BASE__CANCELABLE_LOCK_H_
-#define _INCLUDE__BASE__CANCELABLE_LOCK_H_
-
-#include <base/lock_guard.h>
-#include <base/blocking.h>
-
-namespace Genode {
-
-	class Cancelable_lock
-	{
-		private:
-
-			int volatile _lock;
-
-		public:
-
-			enum State { LOCKED, UNLOCKED };
-
-			/**
-			 * Constructor
-			 */
-			explicit Cancelable_lock(State initial = UNLOCKED);
-
-			/**
-			 * Try to aquire lock an block while lock is not free
-			 *
-			 * This function may throw a Genode::Blocking_canceled exception.
-			 */
-			void lock();
-
-			/**
-			 * Release lock
-			 */
-			void unlock();
-
-			/**
-			 * Lock guard
-			 */
-			typedef Genode::Lock_guard<Cancelable_lock> Guard;
-	};
-}
-
-#endif /* _INCLUDE__BASE__CANCELABLE_LOCK_H_ */

repos/base-fiasco/include/base/ipc_msgbuf.h

@@ -1,65 +0,0 @@
-/*
- * \brief  Fiasco-specific layout of IPC message buffer
- * \author Norman Feske
- * \date   2006-06-14
- */
-
-/*
- * Copyright (C) 2006-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _INCLUDE__BASE__IPC_MSGBUF_H_
-#define _INCLUDE__BASE__IPC_MSGBUF_H_
-
-namespace Genode {
-
-	/**
-	 * IPC message buffer layout
-	 */
-	class Msgbuf_base
-	{
-		protected:
-
-			Genode::size_t _size;
-
-		public:
-
-			/*
-			 * Begin of message buffer layout
-			 */
-
-			Fiasco::l4_fpage_t   rcv_fpage;
-			Fiasco::l4_msgdope_t size_dope;
-			Fiasco::l4_msgdope_t send_dope;
-			char                 buf[];
-
-			/**
-			 * Return size of message buffer
-			 */
-			inline size_t size() const { return _size; };
-
-			/**
-			 * Return address of message buffer
-			 */
-			inline void *addr() { return &rcv_fpage; };
-	};
-
-
-	/**
-	 * Instance of IPC message buffer with specified buffer size
-	 */
-	template <unsigned BUF_SIZE>
-	class Msgbuf : public Msgbuf_base
-	{
-		public:
-
-			char buf[BUF_SIZE];
-
-			Msgbuf() { _size = BUF_SIZE; }
-	};
-}
-
-#endif /* _INCLUDE__BASE__IPC_MSGBUF_H_ */

repos/base-fiasco/include/base/ipc_pager.h

@@ -1,175 +0,0 @@
-/*
- * \brief  Fiasco pager support
- * \author Christian Helmuth
- * \date   2006-06-14
- */
-
-/*
- * Copyright (C) 2006-2013 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _INCLUDE__BASE__IPC_PAGER_H_
-#define _INCLUDE__BASE__IPC_PAGER_H_
-
-/* Genode includes */
-#include <base/cache.h>
-#include <base/ipc.h>
-#include <base/stdint.h>
-#include <base/native_types.h>
-#include <fiasco/thread_helper.h>
-#include <util/touch.h>
-
-/* Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/types.h>
-}
-
-namespace Genode {
-
-	class Mapping
-	{
-		private:
-
-			addr_t             _dst_addr;
-			Fiasco::l4_fpage_t _fpage;
-
-		public:
-
-			/**
-			 * Constructor
-			 */
-			Mapping(addr_t dst_addr, addr_t src_addr,
-			        Cache_attribute cacheability, bool io_mem,
-			        unsigned l2size = L4_LOG2_PAGESIZE,
-			        bool rw = true, bool grant = false)
-			:
-				_dst_addr(dst_addr),
-				_fpage(Fiasco::l4_fpage(src_addr, l2size, rw, grant))
-			{
-				if (cacheability == WRITE_COMBINED)
-					_fpage.fp.cache = Fiasco::L4_FPAGE_BUFFERABLE;
-			}
-
-			/**
-			 * Construct invalid flexpage
-			 */
-			Mapping() : _dst_addr(0), _fpage(Fiasco::l4_fpage(0, 0, 0, 0)) { }
-
-			Fiasco::l4_umword_t dst_addr() const { return _dst_addr; }
-			Fiasco::l4_fpage_t  fpage()    const { return _fpage; }
-
-			/**
-			 * Prepare map operation
-			 *
-			 * On Fiasco, we need to map a page locally to be able to map it to
-			 * another address space.
-			 */
-			void prepare_map_operation()
-			{
-				addr_t core_local_addr = _fpage.fp.page << 12;
-				size_t mapping_size    = 1 << _fpage.fp.size;
-
-				for (addr_t i = 0; i < mapping_size; i += L4_PAGESIZE) {
-					if (_fpage.fp.write)
-						touch_read_write((unsigned char volatile *)(core_local_addr + i));
-					else
-						touch_read((unsigned char const volatile *)(core_local_addr + i));
-				}
-			}
-	};
-
-
-	/**
-	 * Special paging server class
-	 */
-	class Ipc_pager : public Native_capability
-	{
-		private:
-
-			Native_thread_id _last;           /* origin of last fault message   */
-			addr_t           _pf_addr;        /* page-fault address             */
-			addr_t           _pf_ip;          /* instruction pointer of faulter */
-			Mapping          _reply_mapping;  /* page-fault answer              */
-
-		public:
-
-			/**
-			 * Constructor
-			 */
-			Ipc_pager();
-
-			/**
-			 * Wait for a new page fault received as short message IPC
-			 */
-			void wait_for_fault();
-
-			/**
-			 * Reply current page-fault and wait for a new one
-			 *
-			 * Send short flex page and wait for next short-message (register)
-			 * IPC -- pagefault
-			 */
-			void reply_and_wait_for_fault();
-
-			/**
-			 * Request instruction pointer of current page fault
-			 */
-			addr_t fault_ip() { return _pf_ip; }
-
-			/**
-			 * Request fault address of current page fault
-			 */
-			addr_t fault_addr() { return _pf_addr & ~3; }
-
-			/**
-			 * Set parameters for next reply
-			 */
-			void set_reply_mapping(Mapping m) { _reply_mapping = m; }
-
-			/**
-			 * Set destination for next reply
-			 */
-			void set_reply_dst(Native_capability pager_object) {
-				_last.raw = pager_object.local_name(); }
-
-			/**
-			 * Answer call without sending a flex-page mapping
-			 *
-			 * This function is used to acknowledge local calls from one of
-			 * core's region-manager sessions.
-			 */
-			void acknowledge_wakeup();
-
-			/**
-			 * Return thread ID of last faulter
-			 */
-			Native_thread_id last() const { return _last; }
-
-			/**
-			 * Return badge for faulting thread
-			 *
-			 * As Fiasco has no server-defined badges for page-fault messages, we
-			 * interpret the sender ID as badge.
-			 */
-			unsigned long badge() const {
-				return convert_native_thread_id_to_badge(_last); }
-
-			bool is_write_fault() const { return (_pf_addr & 2); }
-
-			/**
-			 * Return true if last fault was an exception
-			 */
-			bool is_exception() const
-			{
-				/*
-				 * Reflection of exceptions is not supported on this platform.
-				 */
-				return false;
-			}
-	};
-}
-
-#endif /* _INCLUDE__BASE__IPC_PAGER_H_ */

repos/base-fiasco/include/base/native_types.h

@@ -14,6 +14,7 @@
 #ifndef _INCLUDE__BASE__NATIVE_TYPES_H_
 #define _INCLUDE__BASE__NATIVE_TYPES_H_
 
+/* Genode includes */
 #include <base/native_capability.h>
 #include <base/stdint.h>
 
@@ -25,8 +26,6 @@ namespace Genode {
 
 	class Platform_thread;
 
-	typedef Fiasco::l4_threadid_t Native_thread_id;
-
 	struct Cap_dst_policy
 	{
 		typedef Fiasco::l4_threadid_t Dst;
@@ -39,57 +38,7 @@ namespace Genode {
 		static void copy(void* dst, Native_capability_tpl<Cap_dst_policy>* src);
 	};
 
-	struct Native_thread
-	{
-		Native_thread_id l4id;
-
-		/**
-		 * Only used in core
-		 *
-		 * For 'Thread' objects created within core, 'pt' points to
-		 * the physical thread object, which is going to be destroyed
-		 * on destruction of the 'Thread'.
-		 */
-		Platform_thread *pt;
-	};
-
-	inline unsigned long convert_native_thread_id_to_badge(Native_thread_id tid)
-	{
-		/*
-		 * Fiasco has no server-defined badges for page-fault messages.
-		 * Therefore, we have to interpret the sender ID as badge.
-		 */
-		return tid.raw;
-	}
-
-	/**
-	 * Empty UTCB type expected by the thread library
-	 *
-	 * On this kernel, UTCBs are not placed within the the context area. Each
-	 * thread can request its own UTCB pointer using the kernel interface.
-	 */
-	typedef struct { } Native_utcb;
-
 	typedef Native_capability_tpl<Cap_dst_policy> Native_capability;
-	typedef Fiasco::l4_threadid_t Native_connection_state;
-
-	struct Native_config
-	{
-		/**
-		 * Thread-context area configuration.
-		 */
-		static constexpr addr_t context_area_virtual_base() {
-			return 0x40000000UL; }
-		static constexpr addr_t context_area_virtual_size() {
-			return 0x10000000UL; }
-
-		/**
-		 * Size of virtual address region holding the context of one thread
-		 */
-		static constexpr addr_t context_virtual_size() { return 0x00100000UL; }
-	};
-
-	struct Native_pd_args { };
 }
 
 #endif /* _INCLUDE__BASE__NATIVE_TYPES_H_ */

repos/base-fiasco/include/base/sleep.h

@@ -1,31 +0,0 @@
-/*
- * \brief  Lay back and relax
- * \author Norman Feske
- * \author Christian Helmuth
- * \date   2006-07-19
- */
-
-/*
- * Copyright (C) 2006-2014 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU General Public License version 2.
- */
-
-#ifndef _INCLUDE__BASE__SLEEP_H_
-#define _INCLUDE__BASE__SLEEP_H_
-
-/* L4/Fiasco includes */
-namespace Fiasco {
-#include <l4/sys/ipc.h>
-}
-
-namespace Genode {
-
-	__attribute__((noreturn)) inline void sleep_forever()
-	{
-		while (true) Fiasco::l4_ipc_sleep((Fiasco::l4_timeout_t){0});
-	}
-}
-
-#endif /* _INCLUDE__BASE__SLEEP_H_ */

repos/base-fiasco/lib/mk/base-common.mk

@@ -4,29 +4,13 @@
 # \date   2013-02-14
 #
 
-LIBS += cxx startup
+include $(BASE_DIR)/lib/mk/base-common.inc
+
+LIBS += startup
 
 SRC_CC += cap_copy.cc
-SRC_CC += ipc/ipc.cc ipc/pager.cc ipc/ipc_marshal_cap.cc
-SRC_CC += pager/pager.cc pager/common.cc
-SRC_CC += avl_tree/avl_tree.cc
-SRC_CC += allocator/slab.cc
-SRC_CC += allocator/allocator_avl.cc
-SRC_CC += heap/heap.cc heap/sliced_heap.cc
-SRC_CC += console/console.cc
-SRC_CC += child/child.cc
-SRC_CC += process/process.cc
-SRC_CC += elf/elf_binary.cc
-SRC_CC += lock/lock.cc
-SRC_CC += signal/signal.cc signal/common.cc signal/platform.cc
-SRC_CC += server/server.cc server/common.cc
-SRC_CC += thread/thread.cc thread/thread_bootstrap.cc thread/trace.cc
-SRC_CC += thread/myself.cc
-SRC_CC += thread/context_allocator.cc
+SRC_CC += signal_submit.cc
+SRC_CC += rpc_dispatch_loop.cc
+SRC_CC += thread.cc thread_bootstrap.cc thread_myself.cc
 
-INC_DIR +=  $(REP_DIR)/src/base/lock
-INC_DIR += $(BASE_DIR)/src/base/thread
-
-vpath cap_copy.cc $(BASE_DIR)/src/platform
-vpath %.cc        $(REP_DIR)/src/base
-vpath %.cc        $(BASE_DIR)/src/base
+vpath cap_copy.cc $(BASE_DIR)/src/lib/startup

repos/base-fiasco/lib/mk/base.mk

@@ -1,18 +1,4 @@
-#
-# \brief  Portions of base library that are exclusive to non-core processes
-# \author Norman Feske
-# \date   2013-02-14
-#
+include $(BASE_DIR)/lib/mk/base.inc
 
-LIBS += base-common
-
-SRC_CC += console/log_console.cc
-SRC_CC += cpu/cache.cc
-SRC_CC += env/env.cc env/context_area.cc env/reinitialize.cc
-SRC_CC += thread/thread_start.cc
-SRC_CC += irq/platform.cc
-
-INC_DIR += $(BASE_DIR)/src/base/env
-
-vpath %.cc  $(REP_DIR)/src/base
-vpath %.cc $(BASE_DIR)/src/base
+SRC_CC += thread_start.cc
+SRC_CC += cache.cc

repos/base-fiasco/lib/mk/platform.inc

@@ -19,7 +19,7 @@ ifeq ($(L4_BUILD_DIR),$(BUILD_BASE_DIR)/l4)
 all: $(L4_SRC_DIR)
 
 $(L4_SRC_DIR):
-	$(VERBOSE)$(ECHO) "--> Please, execute 'make prepare' in $(REP_DIR)"
+	$(VERBOSE)$(ECHO) "--> Please, execute './tool/ports/prepare_port fiasco' in $(GENODE_DIR)"
 	$(VERBOSE)$(ECHO) "--> before compiling Genode apps for Fiasco."
 	$(VERBOSE)exit 1
 endif

repos/base-fiasco/mk/spec-fiasco_x86.mk

@@ -1,25 +0,0 @@
-#
-# Specifics for Fiasco L4v2 on x86
-#
-
-SPECS += x86_32 fiasco
-SPECS += pci ps2 vesa framebuffer
-
-#
-# x86-specific L4v2/sys headers
-#
-L4_INC_DIR   += $(L4_BUILD_DIR)/include/x86/l4v2 \
-                $(L4_BUILD_DIR)/include/x86
-
-#
-# Linker options that are specific for x86
-#
-LD_TEXT_ADDR ?= 0x01000000
-
-#
-# Also include less-specific configuration last
-#
-include $(call select_from_repositories,mk/spec-x86_32.mk)
-include $(call select_from_repositories,mk/spec-fiasco.mk)
-
-INC_DIR      += $(L4_INC_DIR)

repos/base-fiasco/mk/spec-platform_imx.mk

@@ -1,16 +0,0 @@
-#
-# Specifics for Freescale i.MX21 platform
-#
-
-RAM_BASE = 0xc0000000
-
-#
-# Configure target CPU for gcc
-#
-CC_OPT += -march=armv5
-
-#
-# Defines for L4/sys headers
-#
-CC_OPT += -DCPUTYPE_imx
-L4SYS_ARM_CPU = arm_imx

repos/base-fiasco/mk/spec-platform_integrator.mk

@@ -1,14 +0,0 @@
-#
-# Specifics for ARM integrator platform
-#
-
-#
-# Configure target CPU for gcc
-#
-CC_OPT += -march=armv5
-
-#
-# Defines for L4/sys headers
-#
-CC_OPT += -DCPUTYPE_int
-L4SYS_ARM_CPU = arm_int