MINIXCon 2016 Program

Announcement Program



The MINIX3 Service Layer: Recent Past, Current Status, and Near-term Future

David van Moolenbroek
Vrije Universiteit
Amsterdam, The Netherlands

Even though the MINIX3 project is now entirely volunteer driven, it is still seeing quite a lot of activity. As one of the project's core developers, I have been involved in a large number of contributions, including many recent ones. My focus is on the service layer: the set user-space components that, together with the microkernel, make up the actual operating system. The service layer stretches all the way from the system's application programming interface to its hardware drivers.

In this talk, I will start off by giving a high-level overview of the current structure of the MINIX3 project, as well as the current organizational division of labor. In the main part of my talk, I will describe the current status of the MINIX3 service layer, and look at some of the recent and ongoing improvements to it. To the extent that time permits, I will talk about the finalization of the message protocol abstraction, integration of live update support, the new sysctl service and other forms of NetBSD convergence, a file system service built out of libraries, and a sketch for a new network stack. I will end my talk by providing some pointers for those interested in getting involved as contributors

Can MINIX Be "Tuned" in Order to Satisfy Hard Real-time Constraints without Losing Its Soul?

Emery K. Assogba Marc Lobelle
Université catholique de Louvain
ICTEAM, Place Ste Barbe
1348 Louvain-la-Neuve, Belgium
Université catholique de Louvain
ICTEAM, Place Ste Barbe
1348 Louvain-la-Neuve, Belgium

Minix 3 is being modified to have fault-tolerant capabilities against SEU errors (transient errors caused by cosmic radiations, frequent in computer used in satellites for instance). The purpose is to harden user processes. The micro-kernel itself is hardened independently. Redundancy is included at runtime to Minix 3. Program execution is divided in short parts, that we call processing elements (PE). A PE ends at the expiration of the time quantum (or when the process makes a system call or a kernel call before the end of the quantum) that has been drastically reduced in order to be sure that at most one SEU could happen during the processing of each PE. Each PE is executed twice, results are compared by the micro-kernel. If the results differ, the processing of the PE is restarted. In order to compare the results, PE are started with all their memory pages in read only mode. When the PE tries to modify its memory, a copy-on-write is implemented. In this talk, we shall show how the performance of Minix 3 evolves when the duration of the time quantum and frequency of clock interrupts are modified. Results from the "DHRYSTONE" Benchmark Program test will be presented. Also an evaluation of the evolution of the working set (set of modified memory pages) of each process during the redundant execution will be presented

Making Reliable More Reliable: Expanding MINIX 3 with Link Aggregation

Lazar Stričević
Faculty of Technical Sciences
University of Novi Sad
Novi Sad, Serbia

Link aggregation is a set of methods for using multiple parallel links between a pair of devices as if they were a single higher-performance communication channel. It is a way to increase the availability and throughput of the network communication channel between devices without changing the underlying technology. The link aggregation methods can be implemented on various levels of the OSI (Open Systems Interconnection) model, but it is usually done at the data link level. For this reason, many of the modern operating systems have builtin support for link aggregation at data link level. MINIX 3 is designed to be a highly reliable and secure operating system, but at the moment it does not have any kind of system support for the aggregation of network links. However, the modular, flexible internal structure of MINIX 3 allows easy modifications and expansions.

This presentation shows how a feature like link aggregation can be added to MINIX 3 as a separate module without modifying a single existing component of the operating system (except for the configuration files, of course) with minimal performance overhead.The first part of the presentation briefly explains what link aggregation is, what needs to be implemented and how it is implemented in some modern operating systems, such as Linux, Windows and several variants of BSD.

The second part discusses the implementation of the link aggregation module on MINIX 3, with an emphasis on the main issues (e.g. forwarding data frames without copying, link monitoring, ...) and on how they have been dealt with.

The third part of the talk gives the throughput performance test results of the new link aggregation module. The tests have been performed with 100 Mbit/s and 1 Gbit/s Ethernet links to estimate the impact of the new module on the network performance.

Porting MINIX3 to x86-based Hardware

Ralf Neeb

MINIX3 supports x86-based hardware since the beginning. Porting MINIX3 to specific chipsets/boards needed further investigation and analysis to locate the specific requirements of those chipsets/boards. The presentation highlights the process of porting MINIX3 to AMD Geode based chipset (PC Engines ALIX hardware) and to Intel based chipsets (MinnowBoard MAX and LP-172). We present an overview of the ports done and ongoing together with highlighting some of the special small changes required.

Design Patterns for Modular Services, Drivers and Userland

Bernd Onasch GmbH

While porting MINIX to specific hardware the requirement of highly modular services and drivers became apparent. We need standardized MINIX microkernel compliant interfaces on service and driver level to be able to add new hardware components like network cards or complete new platforms. A generalized approach of "starting MINIX up" which is as independent as possible from hardware and boot device will additionally help making new hardware supportable. Using a highly modular approach will allow MINIX to reach out to many platforms so far unsupported.

Participation in the Internet of Things

Michael Schloh von Bennewitz
Europalab Networks R&D

In this half hour, we explore using MINIX on computing nodes participating on a Internet of Things. We consider theory (terms like computers, sensors, actuators, physical web, telemetry, and telecommand) as well as explaining the practice with demonstrations using the mobile IoT lab [1] in combination with MINIX-powered Beaglebone Black computers.

We continue with the topics of data transport and protocols, examining potential NetBSD packages to draw upon for AMQP, ZeroMQ, MQTT, and CoAP networking software. An understanding of why IoT is relevant to our lives and fun to engineer leads to considerations of missing transports (802.3, 802.11, Bluetooth, ZigBee, Z- Wave) and how best to implement them in Minix4, as well as a considerably easier task of porting IoT protocol software from FreeBSD repositories. We contrast with the state of IoT offerings in other platforms, and envison a future in which Minix powered embedded devices fully particpate in an IoT.


Live Update: The Making of

Cristiano Giuffrida
Vrije Universiteit
Amsterdam, The Netherlands

In this talk, I will present ProteOS, the research operating system behind MINIX 3's recent live update support. ProteOS can safely and automatically update all its core OS components, while they are running, with no service interruption. This research introduced new principles in the design of modern live update systems and demonstrated that it is possible to support live update even across very different operating system versions with pervasive code and data changes.

Device Driver Development Demystified

Thomas Cort
Quebec, Canada

Device drivers aren't a black art reserved for grey beards; any programmer can develop them. Discover all of the steps involved in creating a Minix device driver, from documentation gathering and design to implementation and testing from a speaker who's developed multiple device drivers for the BeagleBone. Acquire the strategies necessary to ensure that the process goes smoothly and any bugs are identified and squashed quickly. Also learn how to submit your shiny new driver for inclusion in Minix. Finally, find out why developing device drivers for Minix is such as joy.

Always in the Shadow: The History of MINIX-VMD

Philip Homburg
Amsterdam, The Netherlands

MINIX-VMD is a fork of MINIX 1.6 developed by Kees Bot and Philip Homburg. The goal of Minix-vmd was to go where MINIX could not go. MINIX was to remain simple enough for students to understand. Features such as virtual memory, job control, virtual file systems, etc. were out of scope. Minix-vmd was created to see what MINIX would look like with those features

In this talk I will go over the history of Minix-vmd, highlighting features that sometimes made it into MINIX2, in some cases to be dropped again from MINIX3. Features that never made into any other MINIX version. Features that might be too radical.

Lessons Learned from 30 Years of MINIX

Andy Tanenbaum
Vrije Universiteit
Amsterdam, The Netherlands

MINIX has gone through three major versions since it was introduced in 1987. The goal of MINIX 1 was to be a system students could study in courses and experiment with. The idea was to fill the gap created when Bell Labs forbid teaching UNIX at universities. Before long it was ported to multiple platforms, including the Macintosh, Atari, Amiga, and SPARC.