[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GSoC libchannel project draft

From: Carl Fredrik Hammar
Subject: GSoC libchannel project draft
Date: Fri, 23 Mar 2007 20:30:53 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.96 (gnu/linux)

Hello again!

I have finished writing a draft for the proposal I intend to submit to
Google Summer of Code which I have appended to this mail and I would
appreciate it if someone took their time to read it through.

Since the project could basically be summed up as ``libstore for
character devices'', my main objective with the proposal is to show my
current understanding of libstore but using terminology for channels
;-).  My understanding of libstore comes from extrapolating the
information available in mailing list discussions and libstore's
documentation and I might be on thin ice on some points.  While I can
make up for mistakes in the proposal by commenting it after
submission, I wouldn't want to submit any fundamental misconceptions
on my part.

It has been recommended by some to include my CV into the proposal,
but since I haven't written one and there isn't very much to put into
it, I included some (hopefully) relevant information about myself
directly into the proposal.  Will that do?

Any other wishes and suggestions are also welcomed!


Title   Design and implementation of libchannel for the GNU Hurd
Student Fredrik Hammar


The GNU Hurd has long needed a library that abstracts the idea of a
character device to ease the clean and efficient implementation of the
servers that will implement these.  It has been recognized as needed
for a long time and some tasks have been stalled because of it's lack.

Not only could such a library enable quicker and cleaner
implementations of many translators that directly corresponds to
kernel implemented devices, such as keyboards and mice.  It would also
allow efficient implementations of character devices that are layered
on top of other streams.

The goal of this project is to design, implement and document
libchannel, that will be a library that answers the needs described


There are many cases where a character device is layered on top of
another character device.  For instance, implementing support for
internet over devices other than ethernet cards will require that
the pfinet server can understand frame formats other than ethernet
frames.  The idea here is to make pfinet only understand a single
format and convert to this format from the various formats used by the
devices that supply network access.


Where `device' is the character device providing network access and
`tunnel' is the character device that does the necessary conversion
between frame formats.

This makes the implementation of pfinet independent from the drivers
that supply the connection.  More importantly flexibility is also
gained and writing a translators that balance the network load over
several networks without any change needed for pfinet, is an example
become of what becomes possible.  A schematic of this example is shown


There is a heavy performance penalty for doing it this way, instead of
keeping all the processing of the frames in the pfinet server, the
data needs to be first passed through another process which means a
lot of communication overhead compared to the amount of work actually
needed to do the processing.

The example above is taken from one of the discussions in [1].


Designing and implementing of `libchannel', a library for the GNU Hurd
that eases the clean and efficient implementation of character devices
in the manner described in the previous section.

The need for such a library has long been recognized by the Hurd
community (discussions in [1] took place 2000) and a library for doing
the same thing for block devices, called `libstore' (see [2]), has
already been developed.

Since libchannel is conceptually very similar to libstore, the design
of libchannel will be heavily modeled after libstore.  Not only is it
convenient for me to have such a model to work after, but this analogy
is important for the ease of use of the library.  Having differences
other than the ones stemming from natural differences between blocks
and streams could only bring confusion to the future users of these
two sibling libraries.

The basic idea is that instead of sending the stream of data over IPC,
the channel itself can be sent over IPC and then used directly by the
receiving party.  Thus indirection is avoided.

Similar to libstore, libchannel will define a type that will be a
general channel abstraction. functions working against instances of
this and the means for implementing classes that will provide the
functionality of a channel.

The library will also provide a number of standard classes that are
deemed generally useful. For instance, `device' and `file' channels
that respectively implements a thin wrapper around a device driver in
the kernel and a filesystem node.  These would form a base layer.
Channels layered on top of these can filter the stream, uncompressing
it for instance, or aggregate a number of channels and interleave
them, like balancing network traffic over two NICs.

As a plus, since there is a need to wrap channels around kernel
devices , the library can also be used to cleanly implement character
devices for these drivers with ease.  This in turn leads to a
concentration of the kernel communication into this library that might
be useful in the future, since there has been proposals to switch from
the GNU Mach kernel to a more modern and capable one, see [3].


Below follows a rough sketch on how I plan to tackle this project.

* Study libstore
** Identify and examine classes that could be useful to implement.
** Examine the implementation of IPC in detail.
** Examine how security is achieved.

* Study storeio
** Examine how it uses libstore.

Studies will follow to any dependency of above items if necessary,
such as GNU Mach or libtrivfs.

These preparations might be performed during the interim period as an
exercise to bond with the Hurd community.  As a side-effect the
documentation of studied items might be improved.

* Write a design draft.
** Core functionality.
*** Channel abstraction.
*** IPC.
** Classes.
*** Identify classes that are generally useful.
** Security, identify security considerations.

* Implementation.
** Core functionality.
*** Channel abstraction.
*** IPC.
** Classes.
*** Base classes, e.g. `device' and `file'.
*** Converting and aggregating classes.

* Documentation.

Documentation can to some degree be done in parallel with the

Other ideas

The similarities between libchannel and libstore might be more than
just conceptual.  The libraries might be able to share code through a
third library or it might even be possible to merge them into a single
library.  This could enforce the analogy between them.  I don't think
I dare to commit to alter libstore as well during the course of this
project, but effort will be made in keeping subsystems compatible.

Hopes and dreams

The development of some current and future planned servers of the GNU
Hurd are stalled in wait for libchannel, such as [4].  My hope is that
this project will prove very useful in implementing these and thus
further the ambitions of the GNU Hurd project and freedom for software
users in general.  I to am directly affected by this and can't access
the internet through the GNU Hurd due to PPPoE implementation being
stalled.  Thus I have to use GNU/Linux instead, which is also free of
course, but doesn't offer the flexibility that could be possible
through the GNU Hurd.

This project would also give me much wanted experience in working on
free software development and I hope to be able to use it to
contribute to the Hurd and other free software in the future.

About myself

I was born 1986 in Sweden where I still reside.  I've been interested
in computers since I was a little kid playing around with a Commodore
64 and my interest in free software developed 6 or so years ago, being
around 15 when I first installed GNU/Linux.  Though I have been
interested I have not made any substantial contribution to free
software yet, but have always wanted to.  My interest in the Hurd
started about a year ago, though I happily used it for a while I was
not able to get a internet connection working, thus limiting its
usability for me.

I'm currently at my second year of computer-science studies.  I
currently have no merits in the field outside of academic ones aside
for some small private projects and hope this project will provide me
with some.  My main interests in the field are OSes, compilers and
programming language theory.  Although I have not been able to study
them formally yet.

I am fluent in C, Java, Lisp and Python, but also have a good
understanding of Haskell, SML, C++ and assembly.  I'm also familiar
with the following tools that might be relevant; emacs, autotools,
make and gcc.

My merits might be a bit lacking, but in researching and writing this
proposal I have become confident that I will be able to preform this


[1] Mailing list discussion regarding libchannel - 

[2] Documentation for libstore -

[3] Next Generation Hurd page on the Hurd Wiki - 

[4] Reimplement pfinet -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]