https://training.linuxfoundation.org/resources/free-courses/...
The resources shared by everyone here are so helpful! I’ve been muddling through by reading the docs, source code, and various messages on the mailing list and... it’s been a little painful.
Obviously, RedHat, SuSe Canonical, Microsoft, Apple, AMD, Intel, firmware and embedded companies will always need kernel people. However, the demand has really gone down and it is no more considered "elite" team within companies. Jobs are still there but obviously teams lean towards hiring experts and veterans of kernel instead of new comers. Moreover, once you get over simple char driver and few lines of patch type stuff, kernel development is extremely complex and hard. You wont get much support either as very likely your problem will be unique to your company's hardware. So, my take - learn and do kernel stuff on side but avoid getting into it full-time unless you are really passionate about it.
There are currently a few in AMD's website.
On the other hand, most developers and even some non-developers recognize that kernel development is hard. If you have a name in the kernel development world this will certainly help your reputation. Likewise, if you have a good knowledge of Linux this will certainly help you for certain job openings (kernel development is probably a great background for most low-level job entries).
I’m not sure I understand why this is a bad thing?
You should note the change in the individual commit or the cover letter.
It's the fastest way to get your hands dirty, familiar with a variety of subsystems, and land meaningful, appreciated patches upstream.
`make W=1` to enable additional warnings, find a warning and send a fix. (`make W=123`)
It was very easy for me to make some contributions there.
Last time I checked, the kernel-newbies site doesn't seem to be beginner friendly and aside from following the IRC channel, the mailing list is still the way to do code reviews there, which is quite frankly pre-historic and very unfriendly for beginners sending patches at best.
At least for FreeBSD, they uses Phabricator for code reviews, HaikuOS uses Gerrit and SerenityOS uses GitHub and they seem to be the other OSes that have both good documentation about their kernels and their userland APIs. Perfect places to start learning about operating systems and kernels in general.