Fork of the Genode OS framework
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

236 lines
10 KiB

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.
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
:Organization home page url:
:Main organization license:
GNU General Public License version 2
nfeske, chelmuth
:What is the URL for your Ideas page?:
:What is the main IRC channel for your organization?:
:What is the main development mailing list for your organization?:
: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
: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 [])
: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
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.
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:
:[]: Road-map
:[]: 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.
:[ - Discuss the issue...]:
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/).
:[ - Discuss the issue...]:
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).
:[ - Discuss the issue...]:
; _Since Genode Labs was not accepted as GSoC mentoring organization, the_
; _following section has become irrelevant. Hence, it is commented-out_
; Student applications
; ####################
; The formal steps for applying to the GSoC program will be posted once Genode
; Labs is accepted as mentoring organization. If you are a student interested
; in working on a Genode-related GSoC project, now is a good time to get
; involved with the Genode community. The best way is joining the discussions
; at our mailing list and the issue tracker. This way, you will learn about
; the currently relevant topics, our discussion culture, and the people behind
; the project.
; :[]: Join our mailing list
; :[]: Discuss issues around Genode