=============================================== Release notes for the Genode OS Framework 11.02 =============================================== Genode Labs One year ago, the release 10.02 was our break-through with regard to the support of multiple kernels as base platform for Genode. With the added support for the NOVA hypervisor and the Codezero kernel, Genode applications could be executed on 6 different kernels. With the current release, we take our commitment to kernel platform support even further. With the added support for the Fiasco.OC kernel, we make Genode available on one of the most feature-rich modern microkernels. Additionally, we entered the realms of kernel design with our new platform support for the Xilinx MicroBlaze architecture. This platform support comes in the shape of a custom kernel specifically targeted to the MicroBlaze CPU architecture. Furthermore, we updated our support for the NOVA Hypervisor to the bleeding-edge version 0.3, which has been released earlier this month. With the current support for 8 different kernel platforms (L4/Fiasco, Linux, L4ka::Pistachio, OKL4, NOVA, Codezero, Fiasco.OC, and native MicroBlaze), testing and integrating application scenarios across all platforms becomes increasingly challenging. Therefore, we introduce a new framework for automating such tasks. Thanks to the tight integration of the automation tool with Genode's build system, going back and forth between different kernels becomes an almost seamless experience. Functionality-wise, the release carries on our vision to create a highly secure yet easy to use general-purpose operating system. Because the Genode framework is developed on Linux using the wonderful GNU tools, we consider the availability of the GNU user land on Genode as crucial for using the system by ourself. This motivation drives the creation of a custom execution environment for GNU software on top of Genode. With the current release, we are proud to present the first pieces of this execution environment. Even though not fully functional yet, it clearly shows the direction of where we are heading. Support for Fiasco.OC ##################### The OC in the name of the Fiasco.OC kernel stands for "object capability", hinting at the most significant feature that sets current-generation microkernels such as NOVA, seL4, and Fiasco.OC apart from their predecessors. Whereas previous L4 kernels succeeded in protecting subsystems from each other, the new generation of kernels is geared towards strict security policies. Traditionally, two protection domains were able to communicate with each other if they both agreed. Communication partners were typically globally known via their respective thread/task IDs. Obviously, this policy is not able to guarantee the separation of subsystems. If two subsystems conspire, they could always share information. Object-capability-based kernels are taking the separation much further by prohibiting any communication between protection domains by default. Two protection domains can communicate only if a common acquaintance of both agrees. This default-deny policy facilitates the creation of least-privilege security policies. From the ground up, Genode has been designed as a capability-based system which is naturally capable of leveraging kernel-based object-capability support if present. After NOVA, Fiasc.OC is the second of Genode's base platforms that provides this feature. Apart from being a capability-based kernel, Fiasco.OC has a number of compelling features such as thorough support for ARM platforms and the x86 32/64 bit architectures. It supports SMP, hardware virtualization, and provides special optimizations for running paravirtualized operating systems. Technically, Fiasco.OC is the successor of the L4/Fiasco kernel developed by the OS group of the TU-Dresden. However, the kernel interface of Fiasco.OC has not much in common with L4/Fiasco. Some heritages are still there (e.g., IPC timeouts) but the kernel API has evolved to a fully object-oriented model. :Thanks: We are indebted to the main developer of Fiasco.OC Alexander Warg for being very reponsive to our inquiries while doing the porting work. Thanks to his support, the adaptation of Genode to this kernel has been an almost smooth ride. Prerequisites ============= You need GNU C & C++ Compilers, GNU Binutils, GNU Make, and Perl to use the Fiasco.OC build system. On Debian/Ubuntu systems, you have to install the following packages: ! apt-get install make gawk g++ binutils pkg-config subversion Moreover, you need to download and install the tool-chain used by Genode. Have a look at this page: :[http://genode.org/download/tool-chain]: Genode tool-chain Downloading and building Fiasco.OC ================================== Checkout the Fiasco.OC sources and tool-chain to an appropriated directory: ! export REPOMGR_SVN_REV=27 ! svn cat http://svn.tudos.org/repos/oc/tudos/trunk/repomgr |\ ! perl - init http://svn.tudos.org/repos/oc/tudos fiasco l4re Building the kernel ~~~~~~~~~~~~~~~~~~~ Create the build directory for the kernel: ! cd <path_to_fiasco_src_dir>/src/kernel/fiasco ! make BUILDDIR=<path_to_kernel_build_dir> Go to the build directory, configure the kernel: ! cd mybuild ! make config This will launch the configuration menu. Here you can configure your kernel. The default config is just fine to test the Genode port. It will build a uniprocessor IA32 kernel with debugging features enabled. You can exit the menu and save the configuration by simply typing 'x'. Now, build Fiasco.OC by invoking: ! make Building necessary tools ~~~~~~~~~~~~~~~~~~~~~~~~ To practically use Fiasco.OC, you need in addition to the kernel a tool to bootstrap it, and the initial pager of the system, namely 'sigma0'. Both tools can be found in the L4 runtime environment's base directory. Outgoing from the directory where you checked out the sources, you have to change to the following directory: ! cd <path_to_fiasco_src_dir>/src/l4 Create another build directory: ! make B=<path_to_l4re_build_dir> Again, you might want to tweak the configuration: ! make O=<path_to_l4re_build_dir> config Finally, build the tools: ! make O=<path_to_l4re_build_dir> Building the Fiasco.OC version of Genode ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Fiasco.OC version of Genode is available at the Genode public subversion repository: :http://genode.org/download/subversion-repository: Information about accessing the Genode public subversion repository Go to a directory where you want the Genode/Fiasco.OC build directory to remain. Use the helper script in the 'tool/builddir' directory of the Genode source tree to create the initial build environment. You need to state the absolute path to the build directory of the L4 runtime environment as 'L4_DIR', as it contains the kernel bindings needed by the Genode port. ! <path_to_genode_src_dir>/tool/builddir/create_builddir foc_x86_32 \ ! L4_DIR=<path_to_l4re_build_dir> \ ! GENODE_DIR=<path_to_genode_src_dir> \ ! BUILD_DIR=<path_to_genode_build_dir> Now, go to the newly created build directory and type make. ! cd <path_to_genode_build_dir> ! make Booting Genode on top of Fiasco.OC ================================== Example GRUB configuration entry: ! timeout 0 ! default 0 ! ! title Genode on Fiasco.OC ! kernel /bootstrap -modaddr=0x01100000 ! module /fiasco -serial_esc ! module /sigma0 ! module /core ! module /init ! module /config ! module /pci_drv ! module /vesa_drv ! module /ps2_drv ! module /timer ! module /nitpicker ! module /launchpad ! module /liquid_fb ! module /scout ! module /testnit ! module /nitlog For an example of a matching Genode 'config' file, please take a look at 'os/config/demo'. The Genode binaries are located in '<path_to_genode_build_dir>/bin', the 'fiasco' kernel in '<path_to_kernel_build_dir>'. Assuming you compiled for x86/586 (the default), you can find the 'bootstrap' binary in 'bin/x86_586' and 'sigma0' in 'bin/x86_586/l4f' within the '<path_to_l4re_build_dir>' directory. Current state ============= The adaptation of Genode to Fiasco.OC covers most parts of the Genode API including advanced semantics such as cancelable locks and support for real-time priorities. So far, it has been tested on the x86 architecture. Because 'base-foc' does not contain x86-specific code, we expect no major roadblocks for running Genode on Fiasco.OC on ARM. However, we have not exercised tests in this regard. As of today, there exist the following limitations of the Fiasco.OC support: * The dynamic linker is not yet adapted to Fiasco.OC. Special care must be taken for handling the parent capability for dynamically loaded programs. We have already covered this issue for the NOVA version but the adaptation to Fiasco.OC remains yet to be done. * The destruction of sub systems is not yet fully stable. Because Genode forms a more dynamic workload than the original userland accompanied with the kernel, the usage pattern of the kernel API triggers different effects. We are working with the Fiasco.OC developers to remedy this issue. * The signalling framework is not yet supported. A design exist but it is not implemented yet. We believe however that none of these limitations are a significant hurdle for starting to use Genode with this kernel. Please expect this issues to be resolved with the upcoming Genode release. Technical details about 'base-foc' ================================== The following technical bits are worth noting when exploring the use of Genode with the 'base-foc' platform. * The timer implementation uses a one thread-per-client mode of operation. We use IPC timeouts as time source. Hence, the timer driver is hardware independent and should work out of the box on all hardware platforms supported by Fiasco.OC. * Each 'Server_object' of Genode corresponds to a so-called IPC gate, which is the Fiasco.OC kernel object used for capability invocation. Therefore, protection and object integrity is provided at the fine granularity of single 'Server_objects'. This is in line with our support for NOVA's implementation of capability-based security. * In contrast to the lock implementation that we used with the original L4/Fiasco kernel, the 'base-foc' lock is a fully-featured Genode lock with support for lock cancellation and blocking. For blocking and waking up lock applicants, we use Fiasco.OC's IRQ objects. * The allocator used for managing process-local capability selectors does not yet support the reuse of capability selectors. Further Information =================== :genode/tool/builddir/README: Reference manual for the 'create_builddir' script :[http://os.inf.tu-dresden.de/fiasco]: Official website for the Fiasco.OC microkernel. Noux - an execution environment for the GNU userland #################################################### Even though Genode is currently mainly geared to the classical special-purpose application domains for microkernel-based systems, the main property that sets Genode apart from traditional systems is the thorough support for dynamic workloads and the powerful mechanisms for handling hardware resources and security policies in highly dynamic setting. We are convinced that Genode's architecture scales far beyond static special-purpose domains and believe in the feasibility of Genode as a solid foundation for a fully-fledged general purpose operating system. Internally at Genode Labs, we set up the ultimate goal to switch from Linux to Genode for our day-to-day work. We identified several functionalities that we could not live without and systematically try to bring those features to Genode. Of course, the most fundamental programs are the tools needed to develop and build Genode. Currently we are developing on Linux and enjoy using the GNU userland. Consequently, we require a solution for using this rich tool set on Genode. The straight-forward way for making these tools available on Genode would be running them within a virtualized Linux instance (e.g., using OKLinux on OKL4). However, this approach would defeat our actual goal to create a highly secure yet easy to use working environment because adding Linux to the picture would involve administering the virtualized Linux system. We would prefer a native solution that makes the overall system less, not more, complicated. This way the idea for a native execution environment for the GNU userland on Genode was born. The implementation is called Noux and the first bits of code are featured in the 'ports' repository. Noux consists of two parts, a build environment for compiling GNU programs such that they can be run as Genode processes and an execution environment that provides the classical UNIX functionality to these programs. Noux build environment ====================== From our experience, porting existing UNIX applications to a non-UNIX system tends to be a task of manual and time-consuming labour. One has to loosely understand the build system and the relationship of the involved source codes, implement dummy functions for unresolved references, and develop custom glue code that interfaces the ported application to the actual system. Taking the shortcut of changing the original code has to be avoided at any cost because this produces recurring costs in the future when updating the application. In short, this long-winding process does not scale. For porting a tool set such as the GNU userland consisting of far more than a three-digit number of individual programs, this manual approach becomes unfeasible. Therefore, we have created a build environment that facilitates the use of the original procedure of invoking './configure && make'. The challenge is to supply configure with the right arguments and environment variables ('CFLAGS' and the like) such that the package is configured against the Genode environment. The following considerations must be taken: * Configure must not detect any global headers (e.g., '/usr/include/') or libraries (e.g., '/usr/lib/'). This can be achieved by the '-nostdinc' and '-nostdlib' options * Configure has to use the same include-search paths as used for compiling normal libc-using Genode programs * Configure must use the Genode tool chain * The final linking stage must use the Genode linker script, the Genode base libraries, and other Genode-specific linker arguments. Thanks to the power of the GNU build system, all this can be achieved by supplying arguments to './configure' and indirectly to the 'make' process via environment variables. The new Noux build environment takes care of these precautions. It comes in the form of the 'ports/mk/noux.mk' file which enables the seamless integration of GNU packages with the Genode build system. To compile a GNU package, the manual steps needed are reduced to the creation of a 'target.mk' file representing the package. This 'target.mk' defines the name of the package (by default, the basename of the 'target.mk' enclosing directory is assumed) and the location of the source package. With this approach, we managed to build 'coreutils' (over 100 small UNIX utilities such as 'ls', 'cp', 'sort'), 'binutils' (GNU linker, assembler, object-file tools), 'findutils' ('find', 'xargs'), 'bash', 'dash', GNU make, and finally the GNU compiler collection including 'g++'. The resulting binaries are ready to be executed as native Genode processes. However, without the right environment that presents the program the needed UNIX functionality, those programs won't do much. This leads us to the Noux execution environment. Noux execution environment ========================== The Noux execution environment plays the role of a UNIX kernel for programs built via the Noux build environment. In contrast to a real kernel, the Noux environment is a plain Genode user-level process that plays the role of being the parent of one or multiple Noux processes. In addition of providing the 'Genode::Parent' interface, Noux also provides a locally implemented service called 'Noux::Session' that offers UNIX-like system-calls via an RPC interface. Each hosted program is linked against a special Noux libc plugin that catches all libc calls that would normally result in a system call. It then transparently forwards this function call to the 'Noux::Session' interface. Currently the Noux execution environment implements the following system calls: 'getcwd', 'write', 'stat', 'fstat', 'fcntl', 'open', 'close', 'dirent', 'fchdir', 'read', and 'execve'. The execution environment submits arguments (argc, argv, environment) to the hosted program, manages its current working directory and receives its exit code. File operations are targeted to a custom VFS infrastructure, which principally allows a flexible configuration of the virtual file system visible to the hosted programs. At the current stage, Noux supports mounting plain tar archives obtained from core's ROM service as read-only file system. On startup, the Noux environment starts one process (the init process) and connects the file descriptor 1 (stdout) to Genode's LOG service. State of the implementation ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The infrastructure implemented so far already allows the execution of many simple UNIX tools such as 'ls -lRa', 'echo', 'seq', 'find'. The 'execve' system call is implemented such that a new process is started that inherits the file descriptors and the PID of the calling process. This allows using the exec functionality of the 'bash' shell. However, because 'fork' is not implemented yet, there is currently no way to start multiple programs hosted in a single Noux execution environment. As of today, the Noux environment is not considered to be usable for practical purposes. However, it clearly shows the feasibility of the path we are walking. With the foundation laid, we are looking forward to expanding Noux to a capable solution for running our beloved GNU userland tools on Genode. Vision ~~~~~~ The most significant intermediate result of pursuing the development of Noux is the realization that such an environment is not exceedingly complex. Because of the combination with Genode, we only need to provide a comfortable runtime as expected by user processes but we can leave much of intricate parts of UNIX out of the picture. For example, because we handle device drivers on Genode, we do not need to consider device-user interaction in Noux. As another example, because the problem of bootstrapping the OS is already solved by Genode, there is no need to run an 'init' process within Noux. Our vision foresees that Noux runtimes are to be created on demand for individual tasks such as editing a file (starting a custom Noux instance containing only the file to edit and the text editor), compiling source code (starting a custom Noux instance with only the source code and the build tools). Because Noux is so simple, we expect the runtime overhead of starting a Noux instance to be not more than the time needed to spawn a shell in a normal UNIX-like system. Test drive ~~~~~~~~~~ To give Noux a spin, we recommend using Linux as base platform as this is the platform we use for developing it. First, you will need to download the source code of the GNU packages. From within the 'ports' repository, use the following command: ! make prepare PKG=coreutils This command will download the source code of the GNU coreutils. You may also like to give the other packages a try. To see what is available, just call 'make' without any argument. Create a build directory (e.g., using tool/builddir/create_builddir). Change to the build directory and issue the command ! make run/noux This command will execute the run script provided at 'ports/run/noux.run'. First it builds core, init, and coreutils. Then it creates a tar archive containing the installed coreutils. Finally, it starts the Noux environment on Genode. Noux then mounts the TAR archive as file system and executes 'ls -laR', showing the directory tree. Approaching platform support for Xilinx MicroBlaze ################################################## With the release 11.02, we are excited to include the first version of our custom platform support for the Xilinx MicroBlaze CPU architecture. MicroBlaze is a so-called softcore CPU, which is commonly used as part of FPGA-based System-on-Chip designs. At Genode Labs, we are regularly using this IP core, in particular for our Genode FPGA Graphics Project, which is a GUI software stack and a set of IP cores for implementing fully-fledged windowed GUIs on FPGAs: :Website of the Genode FPGA Graphics Project: [http://genode-labs.com/products/fpga-graphics] Ever since we first released the Genode FPGA project, we envisioned to combine it with the Genode OS Framework. In Spring 2010, Martin Stein joined our team at Genode Labs and accepted the challenge to bring the Genode OS Framework to the realms of FPGA-based SoCs. Technically, this implies porting the framework to the MicroBlaze CPU architecture. In contrast to most softcore CPUs such as the popular Lattice Mico32, the MicroBlaze features a MMU, which is a fundamental requirement for implementing a microkernel-based system. Architecturally-wise MicroBlaze is a RISC CPU similar to MIPS. Many system parameters of the CPU (caches, certain arithmetic and shift instructions) can be parametrized at synthesizing time of the SoC. We found that the relatively simple architecture of this CPU provides a perfect playground for pursuing some of our ideas about kernel design that go beyond the scope of current microkernels. So instead of adding MicroBlaze support into one of the existing microkernels already supported by Genode, we went for a new kernel design. Deviating from the typical microkernel, which is a self-sufficient program running in kernel mode that executes user-level processes on top, our design regards the kernel as a part of Genode's core. It is not a separate program but a library that implements the glue between user-level core and the raw CPU. Specifically, it provides the entrypoint for hardware exceptions, a thread scheduler, an IPC mechanism, and functions to manipulate virtual address spaces (loading and flushing entries from the CPU's software-loaded TLB). It does not manage any physical memory resources or the relationship between processes. This is the job of core. From the kernel-developer's point of view, the kernel part can be summarized as follows: * The kernel provides user-level threads that are scheduled in a round-robin fashion. * Threads can communicate via synchronous IPC. * There is a mechanism for blocking and waking up threads. This mechanism can be used by Genode to implement locking as well as asynchronous inter-process communication. * There is a single kernel thread, which never blocks in the kernel code paths. So the kernel acts as a state machine. Naturally, there is no concurrency in the execution paths traversed in kernel mode, vastly simplifying these code parts. However, all code paths are extremely short and bounded with regard to execution time. Hence, we expect the interference with interrupt latencies to be low. * The IPC operation transfers payload between UTCBs only. Each thread has a so-called user-level thread control block which is mapped transparently by the kernel. Because of this mapping, user-level page faults cannot occur during IPC transfers. * There is no mapping database. Virtual address spaces are manipulated by loading and flushing physical TLB entries. There is no caching of mappings done in the kernel. All higher-level information about the interrelationship of memory and processes is managed by the user-level core. * Core runs in user mode, mapped 1-to-1 from the physical address space except for its virtual thread-context area. * The kernel paths are executed in physical address space (MicroBlaze). Because both kernel code and user-level core code are observing the same address-space layout, both worlds appear to run within a single address space. * User processes can use the entire virtual address space (4G) except for a helper page for invoking syscalls and a page containing atomic operations. There is no reservation used for the kernel. * The MicroBlaze architecture lacks an atomic compare-and-swap instruction. On user-level, this functionality is emulated via delayed preemption. A kernel- provided page holds the sequence of operations to be executed atomically and prevents (actually delays) the preemption of a thread that is currently executing instructions at that page. * The MicroBlaze MMU supports several different page sizes (1K up to 16MB). Genode fully supports this feature for page sizes >= 4K. This way, the TLB footprint can be minimized by choosing sensible alignments of memory objects. Current state ============= The MicroBlaze platform support resides in the 'base-mb' repository. At the current stage, core is able to successfully start multiple nested instances of the init process. Most of the critical kernel functionality is working. This includes inter-process communication, address-space creation, multi-threading, thread synchronization, page-fault handling, and TLB eviction. This simple scenario already illustrates the vast advantage of using different page sizes supported by the MicroBlaze CPU. If using 4KB pages only, a scenario with three nested init processes produces more than 300.000 page faults. There is an extremely high pressure on the TLB, which only contains 64 entries. Those entries are constantly evicted so that threshing effects are likely to occur. By making use of flexible page sizes (4K, 16K, 64K, 256K, 1M, 4M, 16M), the number of page faults gets slashed to only 1.800, speeding up the boot time by factor 10. Currently, there is no restriction of IPC communication rights. Threads are addressed using their global thread IDs (in fact, using their respective indices in the KTCB array). For the future, we are planning to add capabilty-based delegation of communication rights. Building and using Genode on MicroBlaze ======================================= For building Genode for the MicroBlaze platform, you need the MicroBlaze tool chain as it comes with the Xilinx EDK. The tool chain is typically prefixed with 'mb-'. Please make sure that the tool chain's 'bin/' directory is included in your 'PATH' environment variable. For building and starting Genode on MicroBlaze, you first need to create a build directory using the build-directory creation tool: ! tool/builddir/create_builddir microblaze \ ! BUILD_DIR=</path/to/build/dir> \ ! GENODE_DIR=</path/to/genode/dir> The 'base-mb' repository comes with support for Genode's run tool. In order to use it, you will first need to declare the location of your qemu binary using the 'QEMU=/path/to/qemu' variable in the '<build-dir>/etc/microblaze.conf' file. Then you will be able to start an example scenario by issuing the following command from within your build directory: ! make run/nested_init Thereby, the 'run' tool will attempt to start core using the microblaze version of qemu. You can also find a simple hello-world example at 'base-mb/src/test/hello'. The corresponding run script is located at 'base-mb/run/hello.run'. You can execute it via 'make run/hello' from the build directory. Note that currently, all boot modules are linked against the core binary. To change the boot modules, the file 'base-mb/src/core/boot_modules.s' must be modified. For reference, we are using the following tools: * mb-g++ (GCC) 4.1.1 20060524 (Xilinx 11.2 Build EDK_LS2.2 20 Apr 2009 Xilinx 11.2 Build EDK_LS2.2 23 Apr 2009) * GNU ld version 2.16 Xilinx 11.2 Build EDK_LS2.2 23 Apr 2009 * GNU assembler 2.16 Xilinx 11.2 Build EDK_LS2.2 23 Apr 2009 * QEMU emulator version 0.14.50, Copyright (c) 2003-2008 Fabrice Bellard Petalogix linux reference design targeting Xilinx Spartan 3ADSP-1800 boards. Supporting the NOVA hypervisor version 0.3 ########################################## NOVA is a so called microhypervisor - a modern capability-based microkernel with special support for hardware-based virtualization and IOMMUs. Since we incorporated the initial support for the NOVA hypervisor in Genode one year ago, this kernel underwent multiple revisions. The latest version was released earlier this month. To our delight, much of the features that we missed from the initial release had been implemented during the course of the last year. We are especially happy about the fully functional 'revoke' system call and the support for remote kernel-object creation. With the Genode release 11.02, we officially support the latest NOVA version. The update of Genode to the new version required two steps. First, because many details of the kernel interface were changed between version 0.1 and version 0.3, we had to revisit our syscall bindings and adapting our code to changed kernel semantics. Second, we filled our 'base-nova' code related to object destruction and unmapping with life to benefit from NOVA's 'revoke' system call. Consequently, we are now able to run the complete Genode software stack including the dynamic linker on NOVA. Note that for using Genode on NOVA, you will need to apply a small patch to the NOVA source code. This patch enables the re-use of user-level thread control blocks in the kernel. The patch can be found at 'base-nova/patches/utcb.patch'. When executing NOVA on qemu, please specify the '-cpu coreduo' argument to the qemu command line. When using Genode 'run' tool, you may assign this argument to the 'QEMU_OPT' variable in '<build-dir>/etc/build.conf'. :Thanks: We are grateful for the ongoing very pleasant collaboration with Udo Steinberg who is the driving force behind NOVA. Thanks for the ultra-fast responses to our questions and for considering our suggestions regarding the feature set of NOVA's kernel interface! Base framework ############## Upgrading existing sessions =========================== Genode enables a client of a service to lend parts of its own resources to the service when opening a session. This way, servers do not need to allocate own resources on behalf of their clients and become inherently robust against resource-exhaustion-based denial-of-service attacks. However, there are cases when the client can not decide about the amount of resources to lend at session-creation time. In such cases, we used to devise an overly generous client policy. Now, we have added a new 'upgrade' function to the 'Parent' and 'Root' interfaces that enables a client to upgrade the resources of an existing session. For the 'env()->rm_session()' and 'env()->ram_session()' of processes using the Genode 'env' library, we implemented a transparent quota upgrade that kicks in in the event of an exceeded metadata backing store. Comprehensive accounting of core resources ========================================== We changed all services of core to limit their respective resource usage specifically for each individual session. For example, the number of dataspaces that can be handled by a particular region-manager (RM) session depends on the resource donation attached to the session. To implement this accounting scheme throughout core, we added a generic 'Allocator_guard' utility to 'base/include/'. We recommend using this utility when implementing resource multiplexers, in particular multi-level services. Thanks to this change in core, the need for a slack memory reservation in core has vanished. Various changes =============== The remaining parts of the base API underwent no fundamental revision. The changes are summarized as follows. :C++ Support: We removed 'libgcc' from our C++ support library ('cxx') and link it to each individual final target and shared library instead. This change alleviates the need to abuse the 'KEEP_SYMBOLS' mechanism that we used in 'cxx' to keep libc-dependencies of GCC's support libraries local to the 'cxx' library. Besides the benefit of reducing heuristics, this change improves the compatibility with recent cross-compiling tool chains. Furthermore, we added 'realloc' to the local libc support of the 'cxx' library because recent ARM tool chains tend to use this function. :Argument handling for 'main()': We added a hook to the startup code to enable the implementation of custom facilities for passing arguments to the main function. The hook uses the global variables 'genode_argc' and 'genode_argv'. :Child-exit policy hook: We enhanced the 'Child_policy' with a new policy interface that allows a simplified implementation of policies related to program termination. :Changed API of 'Range_allocator': We changed the return value of 'alloc_addr' to distinguish different error conditions. Note that the boolean meaning of the return value is inverted. Please check your uses of 'alloc_addr'! Operating-system services and libraries ####################################### C Runtime ========= In conjunction with our work on Noux, we improved Genode's C runtime at many places. First, we added libstdtime and some previously missing bits of libgdtoa to the libc. These additions largely alleviate the need for dummy stubs, in particular time-related functions. Second, we added the following functions to our libc plugin interface: 'dup2', 'fchdir', 'fcntl', 'fstat', 'stat', and 'write'. This enables the creation of advanced libc plugins simulating a whole file system as done with Noux. Still, there are a number of dummy stubs found at 'libc/src/lib/libc/dummy.cc'. However, those stubs are now all defined as weak symbols such that they can be overridden by libc plugins. Finally, we have replaced the original 'exit' implementation that comes with the libc with a Genode-specific version. The new version reports the exit code of the application to the parent process via an 'Parent::exit()' RPC call. Until now, Genode's libc magically handled output to stdout and stderr by printing messages via Genode's LOG interface. We have now replaced this hard-wired interface by an optional libc plugin called 'libc_log'. If present, write operations to stdout are caught at the libc plugin interface and delegated to the plugin, which implements the output to the LOG interface. If you have an application using Genode's libc, you might consider adding the 'libc_log' library to your 'target.mk' file. Support for big numbers by the means of libgmp and libmpfr ========================================================== We have now include both the GNU Multiple Precision Arithmetic Library and (GMP) and MPFR to the 'ports' repository. This work was specifically motivated by our port of GCC to Genode as GCC version 4.4.5 requires both libraries. Because we intend to use those libraries primarily on x86_32, the current port covers only this architecture. However, expanding the port to further CPU architectures should be straight-forward if needed. Furthermore, you can now also find GCC's 'longlong.h' header at 'libports/include/gcc'. Qt4 updated to version 4.7.1 ############################ The current release bumps the supported Qt4 version from 4.6.2 to 4.7.1 and the Arora web browser (located at the ports repository) from version 0.10.2 to version 0.11. Of course, we updated our custom additions such as our custom Nitpicker plugin widget that enables the seamless integration of native Nitpicker GUI clients into Qt4 applications to work with the new Qt4 version. Tools ##### Tool chain update to GCC 4.4.5 and Binutils 2.21 ================================================ We upgraded the official Genode tool chain from gcc 4.2.4 to gcc 4.4.5. Please update your tool chain by downloading the new binary archive (available for x86_32) or building the tool chain from source using our 'tool/tool_chain' utility. New support for automated integration and testing ================================================= With the growing number of supported base platforms, the integration and testing of Genode application scenarios across all kernels becomes increasingly challenging. Each kernel has a different boot mechanism and specific requirements such as the module order of multiboot modules (Fiasco's bootstrap, Pistachio's sigma0 and kickstart), kernel parameters, or the invocation of a single-image creation tool (OKL4's elfweaver). To make our life supporting all those platforms easier, we have created a tool called 'run', which is tightly integrated within Genode's build system. In short 'run' gathers the intrinsics in the form of a 'run/env' file specific for the platform used by the current build directory from the respective 'base-<platform>' repository. It then executes a so-called run script, which contains all steps needed to configure, build, and integrate an application scenario. For example, a typical run script for building and running a test case resides in a file called '<any-repository>/run/<run-script-name>.run' and looks as follows: ! build "core init test/exception" ! create_boot_directory ! install_config { ! <config> ! <parent-provides> ! <!--<service name="ROM"/>--> ! <service name="LOG"/> ! </parent-provides> ! <default-route> ! <any-service> <parent/> </any-service> ! </default-route> ! <start name="test-exception"> ! <resource name="RAM" quantum="1M"/> ! </start> ! </config> ! } ! build_boot_image "core init test-exception" ! append qemu_args "-nographic -m 64" ! run_genode_until {.*Exception \(label 0xffb0\) occured.*} 10 First, the build system is instructed to create the targets specified as argument for the 'build' function. Next, for the integration part, a new boot directory is created. On most kernel platform, the respective location of the boot directory is '<build-dir>/var/run/<run-script-name>'. Initially, this directory is empty. It gets populated with a 'config' file specified as argument of the 'install_config' command, and by the boot modules specified at the 'build_boot_image' command. Now that the integration is complete, the scenario is executed via the 'run_genode_until' command. This command takes a regular expression as argument, which determines the successful termination of the test case. The second argument is a timeout (is seconds). In the example, the test case will fail if its output does not match the regular expression within the execution time of 10 seconds. The command 'append qemu_args' specifies run-script-specific qemu arguments in the case that qemu is used to execute the scenario. This is the case for most kernel platforms (except for Linux where core gets executed directly on the host). Additional build-directory-specific qemu arguments can be specified in the 'etc/build.conf' file by defining the 'QEMU_OPT' variable. For example, to prevent KVM being used on Ubuntu Linux, specify: ! QEMU_OPT = -no-kvm To execute the run script from with build directory, you need to have Expect installed. Typically, the Linux package is called 'expect'. Simply issue the following command from within your build directory: ! make run/<run-script> Note that you will need to have a GRUB 'stage2_eltorito' binary available at '<genode-dir>/tool/grub' on base platforms that use an ISO image as boot stategy. Because the whole chain of actions, building, integrating, executing, and validating an application scenario is now at the fingertips of issuing a single command with no kernel-specific considerations needed, it has never been easier to run the same scenario on a wide range of different kernels. Please find further instructive examples at 'os/run/'. The 'ldso' run script executes the test of the dynamic linker. It is completely generic. The 'demo' run script starts Genode's default demo scenario and shows how platform-specific considerations (e.g., which device drivers to use) can be taken into account. We found that the 'run' tool significantly boosted our productivity not only for testing purposes but also for accelerating the development-test cycle during our day-to-day work. :Technical notes: The 'run' tool uses Expect as automation tool. Expect is a Tcl interpreter, which is accompanied by special functionality for automating interactive command-line applications. Technically, a run script is an Expect script which gets included by the 'tool/run' script. For the reference of run-specific functions, please revise the documentation in the 'tool/run' script. Because each run script is actual Expect source code, it is possible to use all Tcl and Expect scripting features in a run script. In particular, a run script may issue shell commands using Tcl's 'exec' function. This way, even complex integration tasks can be accomplished. For example, the integration of the Genode Live CD was done via a single run script. Build system ============ To facilitate the integration of 3rd-party build systems into the Genode build process, we added support for pseudo targets that do not require any 'SRC' declaration. Such 'target.mk' may contain custom rules that will be executed when the target is revisited by the build system. The bindings are as follows: ! build_3rd_party: ! ...custom commands... ! ! $(TARGET): build_3rd_party ! ! clean_3rd_party: ! ...custom commands... ! ! clean_prg_objects: clean_3rd_party: