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

List:       haiku-development
Subject:    [haiku-development] Re: Introduction
From:       Rahul Jain <talentediq () gmail ! com>
Date:       2017-05-08 5:57:49
Message-ID: 20170508055711.GA2612 () gmail ! com
[Download RAW message or body]

Hi Axel,
Thanks for a well defined Welcome ;)

On Sun, May 07, 2017 at 04:51:38PM +0200, Axel Dörfler wrote:
> 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.
> 
I would first try to search some error as you mentioned, and will continue to \
investigate/Debug it which will give some good understanding from me. 
> 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).

Yes i made my environment ready and it is working fine on Qemu. 
I will also try setting up a PXE network booting environment. I haven't did it 
Now looks like i have lot to learn :)

Also i have some questions too regarding haiku, I will ask on IIRC.

> 
> Anyway, have fun!
> 
> Bye,
> Axel.
> 
> 

Thanks,
Rahul


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