mirror of
https://github.com/genodelabs/genode.git
synced 2024-12-18 21:27:56 +00:00
237 lines
10 KiB
Plaintext
237 lines
10 KiB
Plaintext
|
|
|
|
==========================
|
|
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:
|
|
|
|
:[http://genode.org/about/road-map]: Road-map
|
|
:[http://genode.org/about/challenges]: Challenges
|
|
|
|
|
|
Combining Genode with the HelenOS/SPARTAN kernel
|
|
================================================
|
|
|
|
[http://www.helenos.org - 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.
|
|
|
|
:[https://github.com/genodelabs/genode/issues/55 - 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/).
|
|
|
|
:[https://github.com/genodelabs/genode/issues/114 - 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).
|
|
|
|
:[https://github.com/genodelabs/genode/issues/113 - 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.
|
|
;
|
|
; :[http://genode.org/community/mailing-lists]: Join our mailing list
|
|
; :[https://github.com/genodelabs/genode/issues]: Discuss issues around Genode
|
|
|