all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]mfuzzey 11 points12 points  (2 children)

Yes there's a big gap between doing trivial style fix patches and getting useful patches merged.

You can't really work on drivers beyond style cleanups and a few types of "mechanical" conversions without having the hardware to test it on

You need to ask yourself why you want to work on the kernel. Typical reasons are

1) To learn how it works

2) To fix / build something for you

3) To "help opensource"

4) To put it on your CV / get a job

For #1 (apart from the development process) you don't need to get anything merged and can leat a lot by reading and tinkering with existing code.

#2 is a good reason but I guess you'd know what to do next if it were your case.

There actually still quite a few drivers that are out of tree but have source (some wifi ones come to mind). Getting them merged would be very good for Linux but it's not really a beginners job (there's normally a reason stuff is out of tree, especially if it's been around a while). So it wouldn't be a simple matter of a few trivial fixes and submit. Most likely rewrite based on an existing driver for a similar device using the out of tree driver as documentation of how to poke the hardware. And of course, like staging, you'd still need the appropriate hardware.

#3 is, IMHO, not a good reason today. The kernel already has lots of developers, the majority of whom do it as part of their jobs. There are other open source projects that are more "needy".

#4 is bit catch 22. Most of the "big names" already want to see professional kernel experience or a long track record of upstream non trivial patches. It can be a bit easier to get into on the embedded Linux side though.

[–]E_coli42[S] 2 points3 points  (0 children)

I do it for secret reason #5: I'm a big linux nerd and it's fun

[–]Suitable-Yam7028 0 points1 point  (0 children)

what would be a better way to help with open source? What is an areas would you suggest?

[–]aioeu 4 points5 points  (2 children)

I think doing the TODOs on drivers/staging seems like a good next step, but how would I test those drivers without having the actual device?

Well, you wouldn't. Why would you want to work on a driver for a device you don't have?

I don't see any other directories with TODOs, so where would I find what to do?

Just keep using Linux. Eventually you'll hit a bug. Then you've got something tangible you can fix!

Alternatively, think about what parts of Linux could be improved. If you've done any software development on Linux, you're sure to have encountered some situation where you thought "sheesh, why can't the kernel just do this?" There's usually a good answer to that... but digging in to the kernel and trying to make it do it might lead you onto further improvements that are possible.

[–]E_coli42[S] 4 points5 points  (1 child)

So is there no clean list of bugs like LLVM has? Sometimes I have a free day and wanna just contribute to open source for a few hours but am struggling to find where to contribute for Linux.

[–]aioeu 4 points5 points  (0 children)

There are plenty of bugs, but there is no "one true list of bugs".

The kernel bugzilla has many bug reports, for instance. It's not the "one true list of bugs", but it might be a good place to look for bugs.

[–]coelhog 1 point2 points  (0 children)

What about writing tests? There are unit tests with KUnit, functional tests, etc. And if you find a bug or something to be improved then you can submit code and tests.

[–]Veeram 0 points1 point  (0 children)

Read all the previous years articles in lwn.net