[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haiku-development
Subject:    [haiku-development] Re: Introduction
From:       Axel_Dörfler <axeld () pinc-software ! de>
Date:       2017-05-07 14:51:38
Message-ID: 0fee3bf7-d612-9c3c-5861-871cdfc51b6a () pinc-software ! de
[Download RAW message or body]

Am 07/05/2017 um 16:10 schrieb Rahul Jain:
> I Found Haiku recently and found it very interesting. Hence Started
> Exploring it. I am very interested to work on Driver Development in Free
> time.

Welcome!

> Currently i am searching for some bugs which can help me in
> understanding Haiku internals.

Lucky for you we have planted quite a lot of them over the years :-)

If you want to get dirty with driver development directly, you'll 
probably find some equipment or device that doesn't yet work with Haiku 
flawlessly or not at all.

Another option would be to add a missing feature to an existing driver, 
for example the AHCI driver doesn't support command queuing yet.
There also isn't an NVMe driver yet; porting an existing driver, or 
writing one from specs can also be a satisfying experience :-)

Working directly with the hardware is a lot trial and error, though, but 
some people certainly like working on that level.

A bit further from the metal would be stuff in the kernel, for example 
search for a simple (read: easily reproducible) bug, and try to find its 
root cause. Following the code paths involved is a good way to get 
accustomed to the source code.

If you're into optimization, there is lots of stuff that you can time, 
and improve considerably (be sure to disable kernel debugging mode, 
though) :-)

Also, you should spend some time on your development environment when 
you picked something of interest; for example, if possible, you should 
always work in emulation when doing kernel development. It speeds up the 
development/test rounds considerably. It's also great to be able to see 
both sides of a device. But for driver development, you often have to 
use a real machine -- in that case, setting up a PXE network booting 
environment is the best way to lower the turnaround times (although, 
IIRC in that case your first job would be to get that to work again).

Anyway, have fun!

Bye,
    Axel.


[prev in list] [next in list] [prev in thread] [next in thread]