Pending work related to kernel for a newbie

[shampavman.cg@gmail.com (sham pavman)]

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 at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160720/0c4b98cb/attachment.html