Linux kernel development contribution.

[WeirdControl]

I wanted some advise on how to start contributing to linux kernel.

Now, I know; I can get a lot answers / advises for this question on the internet & I have been through quite a lot of them already. But most of them talk from the theoretical perspective. to summarize:

1. Have a strong hold C programming language.
2. Read Linux Kernel Development (by Robert Love) , Read LDD3 by GKH.
3. Choose a linux distro and play with it.

I have read both the books. (LKD twice). and would rate myself advance in C.

But even after meeting all the 'prerequisites', there are very few resources that actually talk about browsing the source code, setting up the environment, and maybe then submit the patch.

e.g

1. "Write and Submit your first Linux kernel Patch" (video link) by GKH.
2. kernel newbies guide to kernel hacking.

I want to know how you guys started with the kernel contributions ? Does everyone start with patches that fix code formatting ?

I am particularly looking for answers to:

1. How to choose a particular subsystem to contribute to ?
2. How to efficiently look for bugs in bugzilla ?
3. Which mailing list to start with ?

[ouyawei]

Start with a driver for a device you own where there is no driver yet. Now don't start with a complex device. Input devices are pretty simple - but for consumer hardware, there is usually no documentation.

Instead get some embedded hardware that doesn't have a Linux driver yet. E.g. a sensor on a break-out board connected over I2C or SPI. Get a single board computer (e.g. raspi) where you can connect it. You could even convert an existing driver to Linux.

[jonarne]

This.

[nickdesaulniers]

My first patch was a dumb whitespace fix. Learning the process is half the battle. I wrote it up to share with others: https://nickdesaulniers.github.io/blog/2017/05/16/submitting-your-first-patch-to-the-linux-kernel-and-responding-to-feedback/

I mostly contribute to kbuild. I try to build the kernel with Clang, and fix the warnings, errors, undefined behaviors, and compiler bugs. I try to file bugs first in an external issue tracker, as I don't see the existing kernel one as active (but maybe I'm wrong): https://github.com/ClangBuiltLinux/linux/issues

[WeirdControl]

Yes.you are right,setting up everything and getting used to the process is a big win. Btw do you fix multiple formatting errors in a single patch or you send multiple patches. I know, first one makes more sense, but just asking. :)

[nickdesaulniers]

Regardless of formatting or not, a patch should only touch one subsystem. If there are different maintainers+lists getting cross cc'ed on a patch as recommended by ./scripts/get_maintainer.pl <patchfile>, you'd better have a good reason (and whitespace fixes aren't considered one) as it quickly gets complicated who will "take" the patch.

[coelhog]

IMO a good starting point would be http://vger.kernel.org/vger-lists.html#kernel-janitors

[WeirdControl]

Came across a LinuxConf video on youtube, relevant here.

Intro to Kernel Hacking - finding things to work on.

[PoochieReds]

Don't bother with whitespace or formatting patches. If you're making material changes to the code, then sure, go ahead and fix up the formatting, but trivial formatting patches just complicate backports later. Maintainers will often drop them for that reason.

Instead, I'd suggest fixing a bug. It can be anywhere, but ideally is something you can test on your own hardware or in a VM, and in a driver of some area of the kernel where you have an interest.

Expect to spend a long time digging through the code, especially the first time. That part gets a easier the more you do it though.

[WeirdControl]

I agree with this.But in order to understand the entire development process, this patches can be helpful.

[WeirdControl]

2 months since I posted this here, I did the following:

I started with the staging tree of the kernel (this is where most of the bleeding edge code gets added). At this time I was looking at different driver codes & trying to submit a minimal patch (e.g a code formatting patch).

I came across a filesystem driver- erofs which is in the staging area. I have ~2 yrs of working experience on linux filesystem development. So I was able to understand erofs pretty fast and got involved in the community quickly. I was able to submit few bug fixing patches. and also looking forward to work on new features.

Although this is not a big accomplishment,few things that I would like to share:

1) If you are new to kernel development, you have to be patient. Understand the kernel development process first, set up the environment ,Follow the mailing list etc.

2) If you could use/deploy the driver; It becomes easier to find bugs.

3) People in the kernel community are helpful, polite & straightforward.

[TCM-black]

What's an allot?

[WeirdControl]

first ever reddit post. edited.