Community
 

Google Summer of Code 2012

Genode Labs has applied as mentoring organization for the Google Summer of Code program in 2012. This document summarizes all information important to Genode's participation in the program.

http://www.google-melange.com/gsoc/homepage/google/gsoc2012

Visit the official homepage of the Google Summer of Code program.

Update Genode Labs was not accepted as mentoring organization for GSoC 2012.

Application of Genode Labs as mentoring organization

Organization ID

genodelabs

Organization name

Genode Labs

Organization description

Genode Labs is a self-funded company founded by the original creators of the Genode OS project. Its primary mission is to bring the Genode operating-system technology, which started off as an academic research project, to the real world. At present, Genode Labs is the driving force behind the Genode OS project.

Organization home page url

http://www.genode-labs.com

Main organization license

GNU General Public License version 2

Admins

nfeske, chelmuth

What is the URL for your Ideas page?

http://genode.org/community/gsoc_2012

What is the main IRC channel for your organization?

#genode

What is the main development mailing list for your organization?

genode-main@lists.sourceforge.net

Why is your organization applying to participate? What do you hope to gain?

During the past three months, our project underwent the transition from a formerly company-internal development to a completely open and transparent endeavour. By inviting a broad community for participation in shaping the project, we hope to advance Genode to become a broadly used and recognised technology. GSoC would help us to build our community.

The project has its roots at the University of Technology Dresden where the Genode founders were former members of the academic research staff. We have a long and successful track record with regard to supervising students. GSoC would provide us with the opportunity to establish and cultivate relationships to new students and to spawn excitement about Genode OS technology.

Does your organization have an application templateo?

GSoC student projects follow the same procedure as regular community contributions, in particular the student is expected to sign the Genode Contributor's Agreement. (see http://genode.org/community/contributions)

What criteria did you use to select your mentors?

We selected the mentors on the basis of their long-time involvement with the project and their time-tested communication skills. For each proposed working topic, there is least one stakeholder with profound technical background within Genode Labs. This person will be the primary contact person for the student working on the topic. However, we will encourgage the student to make his/her development transparant to all community members (i.e., via GitHub). So So any community member interested in the topic is able to bring in his/her ideas at any stage of development. Consequently, in practive, there will be multiple persons mentoring each students.

What is your plan for dealing with disappearing students?

Actively contact them using all channels of communication available to us, find out the reason for disappearance, trying to resolve the problems. (if they are related to GSoC or our project for that matter).

What is your plan for dealing with disappearing mentors?

All designated mentors are local to Genode Labs. So the chance for them to disappear to very low. However, if a mentor disappears for any serious reason (i.e., serious illness), our organization will provide a back-up mentor.

What steps will you take to encourage students to interact with your community?

First, we discussed GSoC on our mailing list where we received an overly positive response. We checked back with other Open-Source projects related to our topics, exchanged ideas, and tried to find synergies between our respective projects. For most project ideas, we have created issues in our issue tracker to collect technical information and discuss the topic. For several topics, we already observed interests of students to participate.

During the work on the topics, the mentors will try to encourage the students to play an active role in discussions on our mailing list, also on topics that are not strictly related to the student project. We regard an active participation as key to to enable new community members to develop a holistic view onto our project and gather a profound understanding of our methodologies.

Student projects will be carried out in a transparent fashion at GitHub. This makes it easy for each community member to get involved, discuss the rationale behind design decisions, and audit solutions.

Topics

While discussing GSoC participation on our mailing list, we identified the following topics as being well suited for GSoC projects. However, if none of those topics receives resonance from students, there is more comprehensive list of topics available at our road map and our collection of future challenges:

Combining Genode with the HelenOS/SPARTAN kernel

HelenOS is a microkernel-based multi-server OS developed at the university of Prague. It is based on the SPARTAN microkernel, which runs on a wide variety of CPU architectures including Sparc, MIPS, and PowerPC. This broad platform support makes SPARTAN an interesting kernel to look at alone. But a further motivation is the fact that SPARTAN does not follow the classical L4 road, providing a kernel API that comes with an own terminology and different kernel primitives. This makes the mapping of SPARTAN's kernel API to Genode a challenging endeavour and would provide us with feedback regarding the universality of Genode's internal interfaces. Finally, this project has the potential to ignite a further collaboration between the HelenOS and Genode communities.

Block-level encryption

Protecting privacy is one of the strongest motivational factors for developing Genode. One pivotal element with that respect is the persistence of information via block-level encryption. For example, to use Genode every day at Genode Labs, it's crucial to protect the confidentiality of some information that's not part of the Genode code base, e.g., emails and reports. There are several expansion stages imaginable to reach the goal and the basic building blocks (block-device interface, ATA/SATA driver for Qemu) are already in place.

Virtual NAT

For sharing one physical network interface among multiple applications, Genode comes with a component called nic_bridge, which implements proxy ARP. Through this component, each application receives a distinct (virtual) network interface that is visible to the real network. I.e., each application requests an IP address via a DHCP request at the local network. An alternative approach would be a component that implements NAT on Genode's NIC session interface. This way, the whole Genode system would use only one IP address visible to the local network. (by stacking multiple nat and nic_bridge components together, we could even form complex virtual networks inside a single Genode system)

The implementation of the virtual NAT could follow the lines of the existing nic_bridge component. For parsing network packets, there are already some handy utilities available (at os/include/net/).

Runtime for the Go or D programming language

Genode is implemented in C++. However, we are repeatedly receiving requests for offering more safe alternatives for implementing OS-level functionality such as device drivers, file systems, and other protocol stacks. The goals for this project are to investigate the Go and D programming languages with respect to their use within Genode, port the runtime of of those languages to Genode, and provide a useful level of integration with Genode.

Block cache

Currently, there exists only the iso9660 server that is able to cache block accesses. A generic solution for caching block-device accesses would be nice. One suggestion is a component that requests a block session (routed to a block device driver) as back end and also announces a block service (front end) itself. Such a block-cache server waits for requests at the front end and forwards them to the back end. But it uses its own memory to cache blocks.

The first version could support only read-only block devices (such as CDROM) by caching the results of read accesses. In this version, we already need an eviction strategy that kicks in once the block cache gets saturated. For a start this could be FIFO or LRU (least recently used).

A more sophisticated version would support write accesses, too. Here we need a way to sync blocks to the back end at regular intervals in order to guarantee that all block-write accesses are becoming persistent after a certain time. We would also need a way to explicitly flush the block cache (i.e., when the front-end block session gets closed).

© 2024 Genode Labs