Hi Ashijeet, Its almost always true that we all start off with bugzilla and i believe you should start from there as well. ( pick up bite size bugs) and start solving. However, there is another very important thing. C programming will help you code in a solution to the problem and often that's the most easiest part. Its highly important that you understand the problem first. Understand the subsystems , how they interact . I would urge you to first read about the linux kernel and how it explains all the subsystems and then start looking at the issues. You can solve small issues for the fun of it. But the real strength(at least if you ask me) of a kernel Engineer is to understand the problem first. There are lots of materials online. But if you wish to read any specific book then https://books.google.co.in/books/about/Unix_Internals.html?id=Z7qfu9NK7WQC That's where i started from On Wed, Jul 20, 2016 at 1:24 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:

On Wed, 20 Jul 2016, Aleksander Alekseev wrote:

...

Hello, Ashijeet

...

I am kernel newbie and I was looking for something to work upon to improve my skill-set. I have good knowledge of C and experience in writing patches. Also please refer me if there is a to-do list for newbies related to pending tasks for linux kernel.

I'm newbie here as well. Still I have an experience of working on some other open source projects. I believe the idea is always the same.

First, take a look on project's issue tracker:

https://bugzilla.kernel.org/

Also you could probably review an existing code and propose refactoring or optimization patches. Static code analyzers is always a good start point. Try looking for typos in comments - you will be surprised how many mistakes are there. Usually people like to write code but don't like to document and/or test it. Join testing and reviewing new patches, try to improve them.

I hope this will help.

i've mentioned this before ... if you want a safe project that will still teach you a whole lot about the kernel, improve all the documentation under the Documentation/ directory. there's a *ton* of stuff there that is either in need of improving or, in some cases, deletion because it's so old. or if you're feeling really ambitious, write some *new* documentation for some subsystem for which there is none.

and, finally, you can't screw things up by changing the docs.

rday

--

======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca

Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies