Candidates
This page shows the candidate students and their projects for the Haiku Code Drive 2008:
Salvatore Benedetto
- Porting Bonnie++ to Haiku, which is a benchmark suite that is aimed at performing a number of simple tests of hard drive and file system performance.
- The porting would require to implement XSI semaphore and IPC API, that is ticket 1980
- Once this is all done and working, bug hunting would be next along with fixes.
Project: BFS stress-testing, UDF port to new FS Haiku API
Mentor: Axel Dörfler
The aim of this project is quite different from the others. Instead of proposing to add a new feature, I'd like to work on something R1 related, like making sure that BFS is *STABLE*. Since I'm almost done with Dominic's book about BFS, what I have in mind is to run some tests to stress all the aspects of Haiku's BFS implementation and see where it fails in order to fix the problem and bring the file system a step closer to being stable. To achieve this, I propose to do the following:
Additionally, as a second milestone for my proposal, I also intend to port UDF support to the new FS Haiku API, and if I have some time left, I would like to look also into adding write support to UDF.
Adrien Destugues
- list available devices along with their name, signal strenght and various other informations,
- connect to and disconect from the devices,
- set and configure the stack (allowing the computer to be seen by other devices, disabling or enabling the whole bluetooth system).
Project: Preferences application for the bluetooth stack
Mentor: TBA
Haiku now has a working bluetooth stack able to discover devices and publish the system to other bluetooth enabled devices. In order to make this stack usable for the user, we need a preference application allowing to:
This project is a way for me to get into the haiku community, i wanted to develop for this system for some years (mainly because i used beos for some time), and I think this is the best way to get started. I already started to make small changes to the bluetooth stack and tried it to understand how it does works. I am chatting with Oliver Ruiz Dorantes (bluetooth stack developer) frequently about the stack.
I will code this application even if i'm not selected, because my main goal is to become a member of the Haiku team, but the money will allow me to work full time on it, not having to find another job for the summer.
Jovan Ivankovic
Project: CUPS port
Mentor: TBA
I'm interested in helping bring wider printing support to Haiku. I know very little about Printing kit, but I'm reading through the BeBook and existing code in Haiku source tree. I do not know at which stage the current port is(I know there is Zeta port of Cups here), so I guess it would be even easier to port it to Haiku because of greater posix compliance. I'm also aware of Ithamar Adema's work and his approach on the matter (reusing foomatic database and create Haiku native frontends for existing GhostScript backends) and would like to continue his work.
Yin Qiu
Project: ICMP error handling and propagation
Mentor: TBA
ICMP is a necessary part of the IP protocol family. I will refer to other open source implementations to add ICMP error handling to the Haiku network stack. RFC 792 will be my reference for ICMP segment structure and other implementation details. ICMP messages are usually handled in the OS network stack as a special case. To do so I will study the ICMP message types and ICMP error codes in detail. The error handling mechanism will be implemented with a neat interface. After implementation, I will verify the stack with a Haiku virtual machine and a Linux or Windows host machine.
JiSheng Zhang
Project: Write a DV media node
Mentor: Rene Gollent
As is known to all, a media "node" in Haiku's Media Kit system is a special object that processes buffers of media data. They can be loaded from Add-on modules by the Media Server.
This project will make it easy for Application Programmers to access DV hardware over firewire using the powerful Media Kit APIs without knowing details of firewire protocol and without accessing the somewhat complicated raw interface in /dev.
There are three parts will be implemented. First, a FireWireMediaAddOn class (derived from BMediaAddOn) is used to tell the Media Server the types of nodes it supports and create them when told to do so by the server. Second, A FireWireMediaNode class derived from BBufferProducer, BufferConsumer, BMediaEventLooper which is the major part of this project. Finally, one or more abstract classes which supply convenient methods accessing the raw interface exported by the Firewire stack.