This page will track the FAQs-in-progress, for the kernelnewbies.org FAQs list.
Feel free to add new FAQs, answers, hints to answers (to help others write/edit them), or even links to related pages / posts on the web. If you see any { stub ... } below, and think you can replace it with the requisite useful information, feel free to do so.
Q. How do I write logging data to a file from within the kernel?
A.
- { stub: ... explain why file I/O can't be done directly (process context) ... }
- { stub: ... write about relayfs, debugfs here ... }
- { stub: ... write about why temptation to use procfs should be avoided ... }
Q. How and where to start read Linux kernel code ? Any small project which i can do for gaining experience?
A. Start reading the LKML (Linux Kernel Mailing List). Read all sorts of different threads and gradually you'll pick up on the lingo - you'll probably also learn a thing or two about the kernel at the same time (and it's a great way to pick up info on things that need doing - if you see something discussed that you think you can fix, then you can jump right in and offer to fix it - but don't forget to let people know if you give up so someone else can take over). Don't worry if you don't understand everything at first, just start following the list and pick up the bits you can. (ohh and when you post to the list, don't top-post).
You can also take a look at http://www.kernelnewbies.org/KernelGlossary for a list of the most common terms with short explanations.
Let me see if I can give you some ideas on easy things to start with.
There are lots of things that need doing and some of them don't even require programming skills.
You can help improve the documentation. Even a simple thing such as fixing spelling errors or correcting grammar is worth doing.
It's also helpful if you dig for Kconfig help entries that are blank, work out what the config option is for and write a patch that add a suitable help entry.
You can also help out by simply running the daily git snapshots and/or latest -mm kernels on a regular basis. Use them as your every-day kernel, watch for regressions and bugs (build them with some of the debugging options enabled). Then if/when you spot a regression or bug (make it a habit to check dmesg once in a while), write up a detailed bug report and submit it to the list and relevant maintainers. That's a *very* useful thing to do regardless of anything else you may do. Of course you can also try to actively provoke bugs by stressing different areas of the kernel or just by trying out unusual things. Personally the first thing I do every morning when I turn on my PC is fetch the latest git snapshot from kernel.org, build it, install it, boot it and then use that as my kernel for the day (ok, maybe not every day, but at least I do it every other day). It's of course perfect if you are able to fix the bug you found and can submit a patch along with your bugreport, but it's in no way required, and if you can just submit a detailed well written bug report then that is worth it's weight in gold.
You can also take a look at the Kernel janitors TODO list - http://janitor.kernelnewbies.org/TODO - it lists a lot of minor things that need to be done. A lot of it is pretty trivial and tedious work, but it's often a great place to find some beginners projects to cut your teeth on.
You can also go digging through the source looking for files that don't conform to the official kernel CodingStyle (see Documentation/process/coding-style.rst for details). Then clean up the file so it does conform (hint: scripts/lindent is helpful to get started but don't assume it gets everything right, it needs manual verification and correction).
Another easy thing to get started with is simply build a lot of kernels, log all the output from the build process, look for any warnings or errors that show up, pick one at a time, investigate *why* the compiler warns or errors out, create a patch to fix the problem, submit it, listen to the feedback you get (possibly correct the patch), then move on to the next warning/build error. "make randconfig" is useful to generate a bunch of random configs to build and is an easy way to gather lots of warnings and errors to investigate. This is useful work.
As you get more experienced you can try to get involved in projects discussed on the LKML (you should be following this list regularly by now) that interest you.
I'd say doing a little bit of all of the above is a good way to start. It'll let you get acquainted with a lot of different parts of the kernel. It'll let you get comfortable with submitting patches and working with other developers and you'll be doing useful work fairly quickly.
Some more general advice:
Before you do anything else make sure you have (as a minimum) read the following documents from the kernel source tree:
- README Documentation/admin-guide/reporting-bugs.rst or reporting-issues.rst Documentation/process/howto.rst Documentation/Changes Documentation/admin-guide/bug-hunting.rst Documentation/process/coding-style.rst
Documentation/process/submitting-patches.rst
Documentation/process/submitting-drivers.rst Documentation/process/applying-patches.txt
Online:
I should probably also stress the importance of keeping up-to-date backups of any important data you have on your machine or using a separate development machine when running development kernels. Although bugs that end up eating your files and/or filesystems are rare these days they still happen from time to time, so just make sure that that's not a problem.
Also, when running development kernels you *will* run into Oops'es (crashes) more often than when only running the stable kernels. And when you do, capturing the Oops output is very important, but often the system will be in no state to write it to your logs or you may be in X and don't even see it get printed on the console or the system just hangs. Be prepared to capture bugs, either by running a serial console on another machine where you can record the Oopses when they happen or use netconsole (useful, but not as reliable as serial console in my experience; also requires wired ethernet, not wireless). If you have a parallel port printer (not USB), then console on line printer can also be useful. If you can do none of those, then taking a photo of the screen with the Oops on it or writing it down by hand (*all* of it) will have to do. You probably also want to make sure your kernels have magic sysrq support built in so you can (at least attempt to) do an emergency flush, and unmount of your filesystems when the box hangs followed by an emergency reboot... That's a lot better than just hitting the power button. sysrq can also be used to capture stack traces for running programs, get memory dumps etc. See Documentation/admin-guide/sysrq.txt for details.
Also, please always submit patches in plain text generated with "diff -up" inline in a plain-text email. No HTML mails. No attachments. Plain text with patch inline (and do test send the patches to yourself first the first few times and try applying them to make sure your mailer doesn't mangle them). Also always include a diffstat and a Signed-off-by: line (the above documents have details on this). You also don't want to mix different types of changes in the same patch. If for example you have been doing a warning fix as well as a general CodingStyle cleanup of a file, then don't include both in the same patch but submit two distinct patches instead (in 2 emails) that each do just one thing. Also always include in the description of your patch not just what it does but also *why* it does it.
At some point in time you probably also want to learn how to use git - https://git-scm.com/ - which is what Linus and lots of other core developers use to manage the kernel source.
Some additional pages to visit online for more info etc.: