HelenOS: Ticket Queryhttp://www.helenos.org/query?status=!closed&keywords=~gsoc15&order=priority
HelenOS Operating Systemen-USHelenOShttp://www.helenos.org/chrome/site/helenos_banner.gifhttp://www.helenos.org/query?status=!closed&keywords=~gsoc15&order=priority
Trac 1.2.2http://www.helenos.org/ticket/358
http://www.helenos.org/ticket/358#358: IRQ pseudocode compilerThu, 14 Jul 2011 22:15:27 GMTJiri Svoboda<p>
Devise a programmer-friendly language for describing HelenOS IRQ pseudocode and then implement its compiler and make HelenOS use it.
</p>
<dl class="wiki"><dt>Details</dt><dd>
Level-sensitive interrupts are tricky to handle especially in a microkernel-based operating system in which the device drivers run as userspace processes. The condition which triggered the interrupt must be cleared before the system is ready to receive another interrupt of the same kind (or the device immediately interrupts the system again), but only the userspace driver knows how to do it. This kind of a chicken-and-egg problem must be solved somehow. HelenOS achieves this in a portable way by letting the userspace driver inject a specialized byte code into the kernel. When an interrupt comes, the kernel uses the pseudocode to figure out whether the driver wants to accept the interrupt and also to clear the condition.
</dd></dl>
<blockquote>
<p>
IRQ pseudocode in drivers is typically written as a C initializer (array of structs with designated members). This is not very concise/elegant. What's worse, often we need to substitute constants representing various physical addresses into the code, which is done by patching the individual pseudocode instructions at run time by hand.
</p>
</blockquote>
<blockquote>
<p>
It would be much more elegant to define a text-based language for expressing this symbolic instruction code. Thus the driver could express the pseudocode as a simple string literal that would be then converted to the binary form. The language could allow for named constants, which would make the code much more readable.
</p>
</blockquote>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
It will be easier and more comfortable to write the interrupt-handling part of each driver. The pseudocode will be much more readable and there will be fewer programming errors.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Depending on the devised language, the difficulty will range from easy for an assembly-like language to medium and difficult for a more C-like language, such as the one suggested <a class="new ticket" href="http://www.helenos.org/ticket/358#comment:2" title="#358: enhancement: IRQ pseudocode compiler (new)">here</a> or in <a class="ext-link" href="https://is.cuni.cz/studium/eng/dipl_st/index.php?do=main&amp;doo=detail&amp;did=46276"><span class="icon">​</span>this master thesis</a>.
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C language and the ability to use both the current and the devised language for writing HelenOS IRQ pseudocode. In case of a more sophisticated language, the candidate shall also have an understanding of grammars and various compiler construction techniques.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="missing source">Example of the current IRQ pseudocode in the NE2000 driver</a>
</li><li><a class="new ticket" href="http://www.helenos.org/ticket/358#comment:2" title="#358: enhancement: IRQ pseudocode compiler (new)">Example of possible IRQ pseduocode description language</a>
</li><li><a class="wiki" href="http://www.helenos.org/wiki/DeviceDrivers">Writing Device Drivers for HelenOS</a>
</li><li><a class="ext-link" href="https://is.cuni.cz/studium/eng/dipl_st/index.php?do=main&amp;doo=detail&amp;did=46276"><span class="icon">​</span>Linux kernel userspace modules (master thesis)</a>
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Jiri Svoboda, Jakub Jermar, Martin Decky
</dd></dl>
Resultshttp://www.helenos.org/ticket/358#changeloghttp://www.helenos.org/ticket/402
http://www.helenos.org/ticket/402#402: Port QEMU to HelenOSWed, 21 Dec 2011 19:39:32 GMTJiri Svoboda<p>
Port <a class="ext-link" href="http://wiki.qemu.org/"><span class="icon">​</span>QEMU</a> emulator to HelenOS
</p>
<dl class="wiki"><dt>Details</dt><dd>
QEMU is a machine emulator that is able to emulate environment of various
hardware platforms, including PC, PowerPC, ARM or SPARC.<br />
The goal of porting this emulator to HelenOS is to allow developers run
the emulation of HelenOS inside HelenOS.
It is unlikely that single person would be able to port all features of QEMU
to HelenOS. First of all, the scope of QEMU is really big (it offers also
means for virtualization) to be ported during such short period.
Next, HelenOS itself may not provide all the functionality needed
(for example, there is no port of SDL to HelenOS and the graphical toolkit in HelenOS offers only very limited set of features).<br />
Because of these limitations, the applicant shall choose a reasonable subset
of QEMU features (e.g. it is not necessary to support all emulated peripherals) and focus on porting these.
On the other hand, the solution must provide functional emulator with at least rudimentary graphical output.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
The biggest benefit of this task is in the ability to run HelenOS inside
HelenOS, thus possibly speeding-up development process and, as a more
distant goal, develop HelenOS fully inside HelenOS.
Also, the ability of an OS to run inside itself (i. e. be self-hosting) can be seen as a proof of
maturity of the system.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Medium to High
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX application environment.
Previous experience with development of machine emulator or some virtualization tool would be beneficial to the applicant.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="ext-link" href="http://wiki.qemu.org/"><span class="icon">​</span>QEMU homepage</a>
</li><li><a class="ext-link" href="http://wiki.qemu.org/Manual"><span class="icon">​</span>QEMU user's manual</a>
</li><li><a class="ext-link" href="http://wiki.qemu.org/Documentation/GettingStartedDevelopers"><span class="icon">​</span>Getting started developing QEMU</a>
</li><li><a class="wiki" href="http://www.helenos.org/wiki/BinutilsMaintenance">Maintenance instructions for another ported application (binutils)</a>
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Vojtech Horky
</dd></dl>
Resultshttp://www.helenos.org/ticket/402#changeloghttp://www.helenos.org/ticket/424
http://www.helenos.org/ticket/424#424: RPC/IPC generatorTue, 06 Mar 2012 16:06:54 GMTJiri Svoboda<p>
Implement compiler (generator) for the remote procedure calls over the IPC in HelenOS.
</p>
<dl class="wiki"><dt>Details</dt><dd>
IPC is almost everywhere in HelenOS and most of the time it looks as a remote procedure call (RPC). However, the wrapping code is written by hand although most of it merely wraps IPC calls and error handling. Writing this wrapper code can be quite easily automated to reduce the amount of repetitive code.
<br /><br />
The task is to create an interface definition language (IDL) and a generator that would create the respective C code to execute the RPC.
<br /><br />
The IDL would define interfaces where each interface would have its unique name, optionally list of parent interfaces (that are extended) and a list of methods (calls) and events (callbacks). Each method and event has its name, return type and list of input and output arguments together with their types.
<br /><br />
The IPC in HelenOS is mostly asynchronous and thus the concept of calls and callbacks is necessary. However, the implementation shall not provide only the naive implementation of classical callbacks but also the concept of futures (promises) to allow writing the servers in the same pseudo-synchronous manner as it is today.
<br /><br />
In the first iteration, the IDL can support only basic types (plain integers and blocks of memory would be sufficient for majority of the interfaces), features such as structures or arrays can be added later.
<br /><br />
The result of the compilation (generation) would be a set of C sources and headers files containing:
<ul><li>enums declaring method and event codes
</li><li>typedefs encapsulating the interface instance for server and client
</li><li>method and event ops structures
</li><li>method and event dispatcher (switch statement) - on the called side
</li><li>method and event call marshalling functions - on the calling side
</li><li>method and event call unmarshalling functions - on the called side
</li><li>code to set up and tear down the interface (mainly the callback session)
</li></ul><br />
It would be preferable to have the generator written in Python as most of the build tools are implemented in Python.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
There should be no impact at all to the functionality of HelenOS as an operating system. The benefit would be in making the code more readable because a lot of similar code would be removed, being replaced by an automatically generated one. The presence of such generator would also simplify the process of adding a new interfaces. In the longer term, it would simplify creating bindings for other languages (e.g. OOP-style generator for C++).
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Medium
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C and Python languages and the ability to survive in a non-standard non-POSIX application environment. Knowledge of similar tools (e.g. IDL compiler for CORBA) would be beneficial.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="wiki" href="http://www.helenos.org/wiki/IPC">Introduction to HelenOS IPC</a>
</li><li><a class="wiki" href="http://www.helenos.org/wiki/AsyncSessions">IPC sessions in HelenOS</a>
</li><li><a class="wiki" href="http://www.helenos.org/wiki/Tracing">Tracing IPC calls</a>
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Martin Decky, Jiri Svoboda
</dd></dl>
Resultshttp://www.helenos.org/ticket/424#changeloghttp://www.helenos.org/ticket/517
http://www.helenos.org/ticket/517#517: Port the clang (LLVM) compiler to HelenOSFri, 08 Mar 2013 09:01:30 GMTVojtech Horky<p>
Port the <a class="ext-link" href="http://clang.llvm.org/"><span class="icon">​</span>clang</a> (C frontend to LLVM) compiler to run in HelenOS.
</p>
<dl class="wiki"><dt>Details</dt><dd>
Integrate a reasonably recent version of clang into HelenOS so that it can be used to compile C programs from within HelenOS.
<br /><br />
clang is partially written in C++ and thus it would be necessary to introduce a rudimentary support for C++ into HelenOS libraries. The first requirement is a C++ cross-compiler but that is already prepared by the toolchain script. Next is support for some C++ constructs in HelenOS libraries (exceptions and stack unwinding) that is missing but shall not be that difficult to add. Last thing is the STL but there are many implementations around and it shall not be a big problem to find some BSD-licensed that would be easily portable. Performance of the STL is currently not an issue, the main factor shall be the simplicity of bringing it into HelenOS.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
One of the strategic goals for HelenOS is becoming self-hosting. During previous GSoC, a PCC compiler (Portable C compiler) was ported to HelenOS but it is not possible to compile all sources with it, while clang is able to compile kernel completely and there are only very minor issues with few userspace files. Thus, having clang it would be possible to compile whole HelenOS inside HelenOS (there is already a working port of GNU binutils in HelenOS).
<br /><br />
There is a parallel effort to bring GCC to HelenOS and it would be very nice to have the possibility to choose between more compilers when compiling HelenOS.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Medium
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C and C++ language and the ability to survive in a non-standard non-POSIX application environment. The applicant should also be familiar with the basic concepts behind compilers and the build toolchain.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="wiki" href="http://www.helenos.org/wiki/DeveloperDocs#Clanguage">C language standard</a>
</li><li><a class="wiki" href="http://www.helenos.org/wiki/BinutilsMaintenance">Maintenance instructions for another ported application (binutils)</a>
</li><li><a class="ext-link" href="http://clang.llvm.org/"><span class="icon">​</span>clang homepage</a>
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Vojtech Horky
</dd></dl>
Resultshttp://www.helenos.org/ticket/517#changeloghttp://www.helenos.org/ticket/518
http://www.helenos.org/ticket/518#518: Switch to Waf build systemFri, 08 Mar 2013 14:07:46 GMTVojtech Horky<p>
Rewrite the current make-based build scripts into <a class="ext-link" href="http://code.google.com/p/waf/"><span class="icon">​</span>Waf-based</a> ones.
</p>
<dl class="wiki"><dt>Details</dt><dd>
The build process of HelenOS is currently controlled by make. The build system works well but there is space for improvement that is not possible with Makefiles. The task is to convert currently existing Makefiles into Waf scripts.
<br /><br />
Compiling an operating system usually requires a non-trivial build scripts and, unfortunately, HelenOS is not an exception. Thus, the conversion would not be a trivial search-and-replace exercise. HelenOS has a lot of configuration options that are reflected in the build scripts where they control what has to be built and how. All this would have to be converted and for many of the tasks there are not built-in equivalents in Waf: new tasks would have to be defined and probably a lot of existing ones would have to be changed.
<br /><br />
The effort to switch to Waf started some time ago but due to lack of time was abandoned. It is possible to get inspiration from the obsolete branch located at <a class="ext-link" href="https://code.launchpad.net/~vojtech-horky/helenos/waf"><span class="icon">​</span>lp:~vojtech-horky/helenos/waf</a> and a somewhat more recent branch at <a class="ext-link" href="https://code.launchpad.net/~jakub/helenos/waf-revival"><span class="icon">​</span>lp:~jakub/helenos/waf-revival</a>
<br /><br />
There are a lot of helper tools that are used during the build process and most of them are written in Python. Some changes to them might be necessary as well to better integrate them with Waf.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
Although it is possible to <strong>build out of the source</strong> tree with make, it would require extensive patching of the current Makefiles. Waf offers this automatically. Furthermore, it shall be possible to have different build configurations at the same time in the same source tree. That would allow to incrementally build for different architectures at the same time. This would significantly reduce the time needed to check whether the functionality works okay across different platforms.
<br /><br />
Make supports <strong>parallel build</strong> but this does not work well across directories while Waf has a "global" knowledge of what has to be built and shall provide better parallelization (more evenly balanced).
<br /><br />
Specifying <strong>which library to link the application with</strong> currently means adding both compiler and linker flags to the respective Makefile. With Waf it is possible to specify exported headers for each library and then reference them just by library name. That would simplify writing the application scripts and would also make them more robust.
<br /><br />
Waf scripts are actually snippets of Python code which could be useful in some special situation where writing the logic in an <strong>imperative language</strong> simply makes more sense.
<br /><br />
Last year(s) a lot of effort was invested into making HelenOS <strong>self-hosting</strong>. Porting Python is a necessary prerequisite because of the tools used during the build. Having also the build process controlled by a Python script would reduce the number of other applications that would have to be ported (namely Unix shell, make and makedepend).
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Easy to Medium
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the Python language and good understanding of the compile/link process used when building C programs. Good knowledge of make and related tools is necessary. Prior knowledge of Waf is clearly an advantage.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="ext-link" href="http://code.google.com/p/waf/"><span class="icon">​</span>Waf homepage</a>
</li><li><a class="ext-link" href="https://code.launchpad.net/~vojtech-horky/helenos/waf"><span class="icon">​</span>The old HelenOS/Waf branch</a>
</li><li><a class="ext-link" href="https://code.launchpad.net/~jakub/helenos/waf-revival"><span class="icon">​</span>The unfinished HelenOS/Waf revival branch</a>
</li><li><a class="ext-link" href="http://lists.modry.cz/private/helenos-devel/2012-June/005694.html"><span class="icon">​</span>Mailing-list discussion on out-of-source build in HelenOS</a>
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Vojtech Horky, Jakub Jermar
</dd></dl>
Resultshttp://www.helenos.org/ticket/518#changeloghttp://www.helenos.org/ticket/520
http://www.helenos.org/ticket/520#520: Driver for VESA-compatible graphics adapterWed, 13 Mar 2013 18:26:22 GMTVojtech Horky<p>
Implement a driver for a VESA-compatible graphics card pluggable into the HelenOS graphics stack.
</p>
<dl class="wiki"><dt>Details</dt><dd>
HelenOS has its own compositing server but it currently depends on kernel to properly set the mode of the graphics card. Effectively this means that the configuration of the resolution is done at compile time (through a configuration menu option) and there is no way to e.g. change the resolution at run-time.
<br /><br />
The goal of this ticket is to implement a driver for a graphics card that would be pluggable to the graphics stack and to the driver framework implemented in HelenOS and that would allow the most common operations with the graphics card. Because there is no graphics driver currently implemented in HelenOS, it is reasonable to create a rather simple variant of the driver that would not use any advanced vendor-dependent features but that would only use the VESA BIOS extensions to switch the resolution. The implemented driver shall support following features: Detect possible resolutions and inform the graphics stack about them. Provide an user interface to change the resolution, color depth and possibly refresh rate. Implement the graphics mode-setting. Detection of a second monitor would be a very nice feature.
<br /><br />
Since the protected-mode interface of the VESA BIOS is rather complicated and generally unreliable. the preferred way is to run the real-mode VESA BIOS code in a sandbox environment (e.g. using an x86 emulator). This is a common approach in the majority of operating systems and provides the best degree of compatibility.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
The current VESA BIOS mode setting code in HelenOS is a very minimalistic and involves a boot-time jump to real mode and a kernel driver. Creating a full-fledged graphics driver in user space would allow to remove the kernel driver and reduce the number of relict drivers still present in kernel. It is expected that the user space driver would provide extra features (run-time detection of possible resolution, etc.) that are not available in the kernel driver and that would improve the experience when using HelenOS GUI.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Medium
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with driver or graphics stack implementation would be beneficial.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="wiki" href="http://www.helenos.org/wiki/DeveloperDocs/Peripherals#Graphics">Developer documentation</a>
</li><li><a class="wiki" href="http://www.helenos.org/wiki/UsersGuide/GUI">GUI user's guide</a>
</li><li><a class="ext-link" href="http://lists.modry.cz/cgi-bin/private/helenos-devel/2012-August/008625.html"><span class="icon">​</span>Announcement of the graphics stack at HelenOS mailing list</a>
</li><li><a class="ext-link" href="https://code.launchpad.net/~petr-koupy/helenos/gui"><span class="icon">​</span>lp:~petr-koupy/helenos/gui</a> (original GUI branch)
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Martin Decky
</dd></dl>
Resultshttp://www.helenos.org/ticket/520#changeloghttp://www.helenos.org/ticket/524
http://www.helenos.org/ticket/524#524: Implement support for Ben NanoNote (mips32)Thu, 28 Mar 2013 17:23:15 GMTMartin Decky<p>
Implement support for the Ben NanoNote small form factor computer (mips32 little-endian architecture).
</p>
<dl class="wiki"><dt>Details</dt><dd>
Ben NanoNote is a small form factor portable computer based on the Ingenic Semiconductor JZ4740 SoC (MIPS-II compatible 32bit CPU). The machine is extremely well documented (there are practically no proprietary undocumented hardware components) and while its extensibility is limited to an SDIO port, it can be used as a model hardware for HelenOS since a complete support for it is within the reach of a single trimester work.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
Ben NanoNote would be an ideal demonstrator for HelenOS because it is portable, compact and a complete support for all internal components and common peripherals is within practical reach.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Medium to High
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will need to have very good skills in programming in the C language and the ability to learn how to drive hardware based on various information sources (official documentation, source code of other operating system projects).
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
</dd></dl>
<ul><li><a class="ext-link" href="http://en.qi-hardware.com/wiki/Ben_NanoNote"><span class="icon">​</span>Official Ben NanoNote site with complete documentation</a>
</li></ul><dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Martin Decky
</dd></dl>
Resultshttp://www.helenos.org/ticket/524#changeloghttp://www.helenos.org/ticket/571
http://www.helenos.org/ticket/571#571: Driver for Broadcom VideoCore IV (Raspberry Pi)Sun, 09 Feb 2014 12:58:50 GMTVojtech Horky<p>
Implement a driver for the graphics unit in Raspberry Pi pluggable into the HelenOS graphics stack.
</p>
<dl class="wiki"><dt>Details</dt><dd>
HelenOS can boot on Raspberry Pi but the output is currently limited to serial only.
<br /><br />
The goal of this ticket is to implement a driver for the VideoCore IV chip that would be pluggable to the graphics stack and to the device driver framework implemented in HelenOS. The driver should at least support the HDMI port of Raspberry Pi and setting the optimal graphics mode depending on the output device connected to the HDMI port.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
Currently HelenOS does not provide any form of graphical output when running on Raspberry Pi. Adding support for graphical output would improve the experience when using HelenOS on this platform.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Medium
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with driver or graphics stack implementation would be beneficial.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="wiki" href="http://www.helenos.org/wiki/UsersGuide/GUI">GUI user's guide</a>
</li><li><a class="ext-link" href="http://lists.modry.cz/cgi-bin/private/helenos-devel/2012-August/008625.html"><span class="icon">​</span>Announcement of the graphics stack at HelenOS mailing list</a>
</li><li><a class="ext-link" href="https://code.launchpad.net/~petr-koupy/helenos/gui"><span class="icon">​</span>lp:~petr-koupy/helenos/gui</a> (original GUI branch)
</li><li><a class="ext-link" href="http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf"><span class="icon">​</span>BCM2835 documentation</a>
</li><li><a class="ext-link" href="http://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf"><span class="icon">​</span>VideoCore IV Architecture Reference Guide</a>
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Martin Decky
</dd></dl>
Resultshttp://www.helenos.org/ticket/571#changeloghttp://www.helenos.org/ticket/572
http://www.helenos.org/ticket/572#572: USB DisplayLink driverMon, 10 Feb 2014 09:55:14 GMTVojtech Horky<p>
Implement a driver for a DisplayLink adapter pluggable into the HelenOS graphics stack.
</p>
<dl class="wiki"><dt>Details</dt><dd>
Although HelenOS has its own compositing server, the number of supported graphical adapters is rather low. On PCs, the compositor still relies on kernel to properly initialize the GPU, on other platforms the support is even more rudimentary.
<br /><br />
The goal of this ticket is to implement a driver for a USB DisplayLink adapter that would be pluggable to the graphics stack and to the device driver framework implemented in HelenOS. The driver should support at least proper mode setting (with optimal resolution detection) and unaccelerated graphics output. The driver should be also portable to any HelenOS platform that support the USB bus.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
Implementing a driver for graphical output over USB would allow to use HelenOS graphical interface on any platform with USB support. This would improve the experience when using HelenOS GUI in general. It would also open space for experiments with multi-monitor setup in HelenOS.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Medium
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with driver or graphics stack implementation would be beneficial.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="wiki" href="http://www.helenos.org/wiki/DeveloperDocs/Peripherals#Graphics">Developer documentation (graphics)</a>
</li><li><a class="wiki" href="http://www.helenos.org/wiki/DeveloperDocs/Peripherals#USB">Developer documentation (USB)</a>
</li><li><a class="wiki" href="http://www.helenos.org/wiki/UsersGuide/GUI">GUI user's guide</a>
</li><li><a class="ext-link" href="http://lists.modry.cz/cgi-bin/private/helenos-devel/2012-August/008625.html"><span class="icon">​</span>Announcement of the graphics stack at HelenOS mailing list</a>
</li><li><a class="ext-link" href="https://code.launchpad.net/~petr-koupy/helenos/gui"><span class="icon">​</span>lp:~petr-koupy/helenos/gui</a> (original GUI branch)
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Vojtech Horky
</dd></dl>
Resultshttp://www.helenos.org/ticket/572#changeloghttp://www.helenos.org/ticket/576
http://www.helenos.org/ticket/576#576: Network file server and network file system clientThu, 13 Feb 2014 16:44:22 GMTMartin Decky<p>
Implement and networked file server and networked file system client.
</p>
<dl class="wiki"><dt>Details</dt><dd>
The HelenOS networking stack is mature and there are some networked servers and clients already implemented, but the system still lacks an user-friendly way of accessing remote file systems and serving its own file system to remote hosts over the network.
<br /><br />
The goal of this ticket is twofold: (a) Implementing a networked file server that would serve a part of the local file system in HelenOS to remote host over the network. (b) Implementing a file system client (a file system driver) that would allow to access some remote file server over the network and possibly mount the remote file storage as a file system.
<br /><br />
Both the server and the client should support at least one of the following common communication protocols. The server and the client for HelenOS should also have at least some protocols in common in order to be interoperable.
<ul><li>SFTP
</li><li>9P
</li><li>SMB
</li><li>NFS
</li></ul></dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
Having a working and interoperable file server and file system client will have a huge number of benefits for HelenOS, ranging from easier debugging and testing (accessing the files of the running HelenOS system remotely and storing data to remote hosts) to practical day-to-day usability.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Medium to High
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C languages and the ability to survive in a non-standard non-POSIX application environment. Experience with networking in general and file sharing protocols in particular will be very beneficial.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="ext-link" href="http://tools.ietf.org/search/draft-ietf-secsh-filexfer-13"><span class="icon">​</span>SFTP protocol specification</a>
</li><li><a class="ext-link" href="http://plan9.bell-labs.com/sys/man/5/INDEX.html"><span class="icon">​</span>9P protocol specification</a>
</li><li><a class="ext-link" href="http://msdn.microsoft.com/en-us/library/cc246231.aspx"><span class="icon">​</span>SMB protocol specification</a>
</li><li><a class="ext-link" href="https://www.ietf.org/rfc/rfc3530.txt"><span class="icon">​</span>NFSv4 protocol specification</a>
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Martin Decky
</dd></dl>
Resultshttp://www.helenos.org/ticket/576#changeloghttp://www.helenos.org/ticket/577
http://www.helenos.org/ticket/577#577: AC'97 Audio driverSun, 16 Feb 2014 06:32:24 GMTJan Vesely<p>
Implement a driver for an audio device compliant with the AC'97 specification pluggable into the HelenOS audio subsystem (Hound).
</p>
<dl class="wiki"><dt>Details</dt><dd>
Although HelenOS has a sound server that can mix output from multiple applications, currently only Sound Blaster 16 and Intel HDA hardware is supported. This former is not practically usable on today's hardware outside of emulators such as QEMU.
<br /><br />
The goal of this ticket is to implement a driver for AC'97 class of audio devices that would be pluggable into to the sound subsystem and to the device driver framework implemented in HelenOS. The driver should at least support audio playback on virtual devices emulated in <a class="missing wiki">VirtualBox?</a> and QEMU and optionally on actual hardware.
<br /><br />
AC'97 devices are simpler than Intel HDA devices. This ticket should be considered an easier alternative to ticket <a class="closed ticket" href="http://www.helenos.org/ticket/575" title="#575: enhancement: Intel HD Audio driver (closed: fixed)">#575</a>. The difficulty can be further scaled down by limiting the scope to a specific AC'97 revision.
</dd></dl>
<dl class="wiki"><dt>Gains and Benefits</dt><dd>
Although replaced by the newer Intel HDA standard, the AC'97 devices were the de facto standard in previous generations of sound cards for PC. Implementing a driver for sound output output via Intel HD Audio would allow to use HelenOS sound system on real hardware, improving the user experience and overall usefulness of the system from the end-user point of view.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Medium
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with driver or sound system implementation would be beneficial, as well as the knowledge of I/O device architecture (PCI, MMIO, DMA).
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="ext-link" href="http://download.intel.com/support/motherboards/desktop/sb/ac97_r23.pdf"><span class="icon">​</span>Audio Codec ‘97</a>
</li><li><a class="ext-link" href="http://download.intel.com/design/chipsets/manuals/29802801.pdf"><span class="icon">​</span>Intel ® 82801AA (ICH) &amp; Intel ® 82801AB (ICH0) I/O Controller Hub AC ’97</a>
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Jiri Svoboda
</dd></dl>
Resultshttp://www.helenos.org/ticket/577#changeloghttp://www.helenos.org/ticket/621
http://www.helenos.org/ticket/621#621: Raspberry Pi USB controller driverFri, 13 Feb 2015 16:12:30 GMTJakub Jermář<p>
Implement driver for the Raspberry Pi USB controller that will be part of the HelenOS DDF (Device Driver Framework) and USB stack.
</p>
<dl class="wiki"><dt>Details</dt><dd>
HelenOS features basic support for the popular and inexpensive Raspberry Pi credit-card sized computer. HelenOS can also boast its own USB stack, but because Raspberry Pi uses a non-standard USB controller, HelenOS cannot unfold its full potential on this platform, where most of the peripherals are meant to be attached via USB (mouse, keyboard, network).
<br /><br />
A prerequisite for the Raspberry Pi USB controller driver would be a simple Raspberry Pi platform driver that would provide attachment points for the USB controller driver and possibly also for other drivers. This small driver represents an ideal qualification task for GSoC students who wish to work on this project.
<br /><br />
HelenOS currently supports USB 1.1 and USB 2.0. USB 3.0 development branch is available on GitHub and is awaiting integration into the main development branch. The Raspberry Pi USB controller can be programmed either for USB 1.1 or USB 2.0.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
With this driver implemented, it will suddenly become possible to use standard USB devices such as mice and keyboards on HelenOS/Raspberry Pi.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Medium
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX environment. Previous experience with driver or USB stack implementation would be beneficial.
</dd></dl>
<dl class="wiki"><dt>Documentation and references</dt><dd>
<ul><li><a class="wiki" href="http://www.helenos.org/wiki/DeveloperDocs/Peripherals#USB">Developer documentation (USB)</a>
</li><li><a class="ext-link" href="http://en.wikipedia.org/wiki/Raspberry_Pi#cite_note-VerifiedPeripheralList-10"><span class="icon">​</span>Raspberry Pi on Wikipedia</a>
</li><li><a class="ext-link" href="http://networkdirection.net/images/stories/RPi%20-%20USB%20Controller%20v1.03.pdf"><span class="icon">​</span>Raspberry Pi USB controller</a>
</li><li><a class="ext-link" href="http://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md"><span class="icon">​</span>Raspberry Pi USB documentation on Raspberry Pi project homepage</a>
</li><li><a class="ext-link" href="http://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/README.md"><span class="icon">​</span>BCM2835 chip documentation on Raspberry Pi project homepage</a>
</li><li><a class="ext-link" href="https://github.com/helenos-xhci-team/helenos"><span class="icon">​</span>Development branch with USB 3.0 support</a>
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Jakub Jermar
</dd></dl>
Resultshttp://www.helenos.org/ticket/621#changeloghttp://www.helenos.org/ticket/11
http://www.helenos.org/ticket/11#11: Support PAE on ia32Thu, 09 Apr 2009 13:37:38 GMTJakub Jermář<p>
Add support for Physical Address Extension to our ia32 port so that more than 4G of physical memory can be addressed.
</p>
<dl class="wiki"><dt>Details</dt><dd>
On all currently supported 32-bit platforms (arm32, ia32, mips32, ppc32), HelenOS assumes 32-bit physical addresses. This allows the system to make use of 4G of physical memory in total. Some of these architectures, however, provide extensions (e.g. PAE on ia32, LPAE on arm32) that make it possible to address more physical memory by using wider physical addresses (e.g. 36-bit or 40-bit).
</dd></dl>
<blockquote>
<p>
There are actually two goals for this project. The first is to modify HelenOS to use a dedicated type for representing physical addresses instead of the current <code>uintptr_t</code> or <code>void *</code>, because the assumption that both virtual and physical addresses have the same amount of bits will no longer hold. The second goal is to implement the actual support for PAE in the form of PAE page table format and PAE feature detection and initialization.
</p>
</blockquote>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
By having the PAE support on ia32, HelenOS will be able to utilize more of the installed memory. HelenOS will also become ready to support similar features on other architectures (think LPAE on arm32).
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
High
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
Kernel programming skills are needed and the applicant should be strong in C and should have the ability to understand the HelenOS memory management subsystem quickly.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
</dd></dl>
<ul><li><a class="wiki" href="http://www.helenos.org/wiki/DeveloperDocs/CPUArch#IA-32">Developer documentation for IA-32 architecture</a>
</li><li><a class="ext-link" href="https://github.com/HelenOS/helenos/blob/master/kernel/doc/mm#L6"><span class="icon">​</span>HelenOS abstraction for virtual address translation</a>
</li><li><a class="ext-link" href="https://github.com/HelenOS/helenos/tree/master/kernel/arch/ia32/src/mm"><span class="icon">​</span>Memory management implementation for IA-32</a> (<a class="ext-link" href="https://github.com/HelenOS/helenos/blob/master/kernel/arch/ia32/include/arch/mm"><span class="icon">​</span>headers</a>)
</li></ul><dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Jakub Jermar
</dd></dl>
Resultshttp://www.helenos.org/ticket/11#changeloghttp://www.helenos.org/ticket/40
http://www.helenos.org/ticket/40#40: Implement support for Sgi Octane (mips64)Fri, 10 Apr 2009 11:27:06 GMTMartin Decky<p>
Implement support for Sgi Octane machines (mips64 big-endian architecture).
</p>
<dl class="wiki"><dt>Details</dt><dd>
The Octane is a SMP machine built by Sgi in the 1997 - 2000 time frame. It is based on the MIPS R12000 CPU and a proprietary Crossbow ASIC crossbar switch instead of a system bus. It uses the ARCS boot firmware and originally runs with Sgi IRIX. The goal of this ticket is to implement at least a basic support for Sgi Octane (basic kernel functionality), i.e. support for booting, memory management, SMP, framebuffer output and keyboard input.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
Sgi Octane is an excellently engineered workstation with 64bit MIPS CPUs, SMP support and interesting hardware design that is inspiring even after many years. Implementing HelenOS support for Octane should hint any possible portability issues in HelenOS and it should also improve some minor functionality aspects of the kernel.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Very high
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
Since there is very little publicly available hardware documentation of the Sgi Octane (except the CPU itself and other discrete components), the HelenOS support needs to be largely based on the reverse-engineered code in <a class="ext-link" href="http://www.linux-mips.org/~skylark/"><span class="icon">​</span>Linux</a> and <a class="ext-link" href="http://www.openbsd.org/sgi.html"><span class="icon">​</span>OpenBSD</a>. Therefore a successful applicant will need to have very good skills in programming in the C language and the ability to learn and reuse know-how contained in reverse-engineered code of other operating system projects.
</dd></dl>
<dl class="wiki"><dt>Note</dt><dd>
We have a single Sgi Octane machine physically available for development, debugging and testing.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
</dd></dl>
<ul><li><a class="ext-link" href="http://www.linux-mips.org/~skylark/"><span class="icon">​</span>Linux Sgi Octane port</a>
</li><li><a class="ext-link" href="http://www.openbsd.org/sgi.html"><span class="icon">​</span>OpenBSD Sgi Octane port</a>
</li></ul><dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Martin Decky
</dd></dl>
Resultshttp://www.helenos.org/ticket/40#changeloghttp://www.helenos.org/ticket/310
http://www.helenos.org/ticket/310#310: Support for DWARF Debugging Information FormatTue, 08 Mar 2011 20:42:42 GMTJakub Jermář<p>
Implement support for an essential subset of the DWARF Debugging Information Format in HelenOS.
</p>
<dl class="wiki"><dt>Details</dt><dd>
The DWARF Debugging Information Format is a rich, processor architecture independent debugging format supported by the toolchain used to build HelenOS. It encodes information that may otherwise be hard or impossible to get during HelenOS run-time. The goal of this project is to identify aspects of the DWARF format that would improve the debugging capabilities and observability of both the HelenOS kernel and applications, and bring support for those aspects to HelenOS. An example of such an aspect is the support for reliable call stack unwinding.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
Besides other possible benefits that depend on the supported features, one key benefit would be the ability to reliably generate stack traces on some architectures that are not stacktracing-friendly, such as mips32.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Medium
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C language and at least basic familiarity with binutils, gcc and linker scripts. This project may expose the candidate to mips32 assembly.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="wiki" href="http://www.helenos.org/wiki/DeveloperDocs#DebuggingData">DeveloperDocs</a>
</li><li><a class="ext-link" href="http://dwarfstd.org/"><span class="icon">​</span>Dwarf Home</a>
</li><li><a class="ext-link" href="http://dwarfstd.org/doc/Dwarf3.pdf"><span class="icon">​</span>DWARF 3</a>
</li><li><a class="ext-link" href="http://dwarfstd.org/doc/DWARF4.pdf"><span class="icon">​</span>DWARF 4</a>
</li></ul>
</dd><dt>Possible mentors</dt><dd>
HelenOS Core Team, Jakub Jermar
</dd></dl>
Resultshttp://www.helenos.org/ticket/310#changeloghttp://www.helenos.org/ticket/425
http://www.helenos.org/ticket/425#425: Implement support for Lemote Fuloong/Yeeloong (mips64)Wed, 07 Mar 2012 15:26:39 GMTMartin Decky<p>
Implement support for Lemote Fuloong and/or Yeeloong machines (mips64 little-endian architecture).
</p>
<dl class="wiki"><dt>Details</dt><dd>
Fuloong is a mini-PC and Yeeloong is a netbook built by Lemote and based on the Loongson 2F CPU, which is itself a MIPS64-derived CPU developed at the Institute of Computing Technology at Chinese Academy of Sciences. Both machines use industry-standard components such as a PCI bus, USB, SATA, etc. They use the U-boot boot loader as a firmware and runs Linux. The goal of this ticket is to implement at least a basic support for either machine, i.e. support for booting, memory management, framebuffer output, PCI support, USB support and USB keyboard support.
</dd></dl>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
The Lemote machines are decent and state-of-the-art desktop/netbook machines with a 64bit MIPS CPU and very popular in the academia not only in China. Implementing HelenOS support for the Loongson CPU should hint any possible portability issues in HelenOS and it should also improve some minor functionality aspects of the kernel.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
High
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will need to have very good skills in programming in the C language and the ability to learn how to drive hardware based on various information sources (official documentation in English and Chinese, source code of other operating system projects and emulators).
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
</dd></dl>
<ul><li><a class="ext-link" href="http://dev.lemote.com/"><span class="icon">​</span>Lemote development resources</a>
</li><li><a class="ext-link" href="http://dev.lemote.com/wiki/"><span class="icon">​</span>Lemote wiki</a>
</li><li><a class="ext-link" href="http://dev.lemote.com/trac/"><span class="icon">​</span>Lemote-related projects</a>
</li></ul><dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Martin Decky
</dd></dl>
Resultshttp://www.helenos.org/ticket/425#changeloghttp://www.helenos.org/ticket/526
http://www.helenos.org/ticket/526#526: Port DOSBox to HelenOSThu, 28 Mar 2013 18:59:32 GMTMartin Decky<p>
Port the <a class="ext-link" href="http://www.dosbox.com/"><span class="icon">​</span>DOSBox x86 emulator</a> to HelenOS
</p>
<dl class="wiki"><dt>Details</dt><dd>
DOSBox is a special-purpose x86 emulator targeting primarily 1980's and 1990's DOS games and applications. It contains an integrated emulator of MS-DOS system calls, command interpreter and various other components. It tries to faithfully emulate specific hardware devices (e.g. VGA and SVGA graphics cards, various sound cards, etc.) while several other hardware models are extremely simplified. This allows DOSBox to run many real-mode and protected-mode applications from the "golden" MS-DOS era, but it is not a complete machine emulator in the usual sense.
</dd></dl>
<blockquote>
<p>
The goal is to port DOSBox to HelenOS (using the native HelenOS graphics stack), preserving the most important features while possibly omitting others (e.g. the sound output). The solution must provide a functional emulator with at least rudimentary graphical output.
</p>
</blockquote>
<dl class="wiki"><dt>What Gains and Benefits will this bring?</dt><dd>
DOSBox would be a great application for testing and optimization of the brand new graphics stack of HelenOS. And of course, the basic possibility to play some vintage DOS games in HelenOS might make the system more attractive for hobbyists.
</dd></dl>
<dl class="wiki"><dt>Difficulty</dt><dd>
Medium
</dd></dl>
<dl class="wiki"><dt>Required skills</dt><dd>
A successful applicant will have good skills of programming in the C language and the ability to survive in a non-standard non-POSIX application environment. Previous experience with the source code of DOSBox, SDL and other software components would be beneficial.
</dd></dl>
<dl class="wiki"><dt>Documentation</dt><dd>
<ul><li><a class="ext-link" href="http://www.dosbox.com/"><span class="icon">​</span>DOSBox x86 emulator</a>
</li><li><a class="ext-link" href="http://sourceforge.net/projects/dosbox/files/dosbox/0.74/"><span class="icon">​</span>DOSBox source code</a>
</li></ul></dd></dl>
<dl class="wiki"><dt>Possible mentors</dt><dd>
HelenOS Core Team, Martin Decky
</dd></dl>
Resultshttp://www.helenos.org/ticket/526#changelog