Quark Project

From air
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Encadrants: Olivier Gruber

Elèves 5A: Lucas Chaloyard et Elias El Yandouzi.


This project is a great opportunity to experience low-level system design and implementation, contributing to the Quark research prototype. The Quark research explores the design and implementation of micro-kernels based on the concept of distributed and collaborating tiles where each tile is a simple virtual machine offering one or more cores, some memory, and a network interface. A first prototype is functional and you will be contributing to assess its features and evaluate its performance. If this project validates the prototype, a first version will be released as an open-source research project and your contributions will be cited.

The project will start with designing and implementing a self-testing totally-ordered multicast test on top of Quark. The first goal is to assess the Quark features, using them for a realistic workload that offers an easy self-testing behavior. The second goal is to help polish these features, improving their design or simply finding and resolving bugs. A third goal is to improve the implementation of these features if the performance evaluation calls for such improvements.

You will be working closely with Pr. Olivier Gruber, who has designed and coded the current prototype. This is not a solo project, this is a team effort with Pr. Olivier Gruber as the technical lead. Your code is to be integrated and kept as a stable test for the Quark microkernel. The environment will be a gitlab project.

The coding will be in the C programming language in the context of small ARM-based embedded systems. The usual GNU tools will be used and the development platform is Linux. The C programming will be low-level programming, in a constrained environment, without the usual libraries or frameworks. For debugging, we use GDB and QEMU as well as Valgrind. It is expected that the written code will be of good quality and understood by the technical lead, so that it can be maintained in the coming years.

The project is already well planned, which almost guarantees success, and yet,because it is coded directly on top of a microkernel, running directly on the hardware, the opportunities to learn and contribute are many, making this project uniquely interesting and challenging. The different sprints have already been planned as follows:

  • A simple group builder service to build a group of peers. It will be a very good warmup to the Quark development environment and the necessary first step to our totally-ordered multicast. There are already examples to help you get started.
  • Implement a totally-ordered multicast, based on the Lamport's clock. Above the multicast, a simple burst-oriented self-testing application whose purpose is to stress test Quark. Again, a simple step forward since we will not consider failures and the test will run entirely locally within a single tile.
  • Introduce the support for a dynamic group of peers : This means that peers may leave and rejoing the group, voluntarily. We will still only consider running locally but we can start expecting bugs within Quark as we are pushing some of the untested features. This will expose you to the internals of Quark.
  • Move to a distributed execution across tiles. Multi-tile execution means one tile per peer executing on different machines. We can start expecting bugs within Quark as we are pushing some of the untested features. We can also expect to find interesting challenges in terms of performance. This will expose you to the internals of Quark.