I frequently see people getting scared when they try to do kernel development, because they see that there is no C library. Common false beliefs include but not limited to:

1. No printf(), how would I debug my code?
2. If I write mess, my hardware will blow up!
3. Takes too much effort even to print out a string!

Here are my answers to them:

1. Of course there is no printf(), because there isn't any standard output. For debugging, we have printk(), which is (almost) exactly the same.
2. No, the kernel will crash. Nowadays, the Linux Kernel is so evolved that it will take great efforts to cause hardware problems. Obviously, if you are a hardware vendor and you mess up your own hardware, then we can't do anything for you. :-)
3. It depends. If you start to write your own kernel, yes it does. The minimal kernel I could write that printed out a string was like 15 lines. But with Linux, and you really should develop that, you already have the already mentioned printk()

So, now that all the fear has been chased away, let's talk about how could you contribute to the kernel. Well, it turns out that some very clever kernel developers already created the perfect tool to push you in the right direction. There is a file called 'scripts/checkpatch.pl'. This file finds common code style issues in the code. There is a gotcha with this, you shouldn't use this on normal, upstream code, because those patches do less good than bad, because they create noise. Checkpatch-patches are noise when trying to bisect a bug for example. Fortunately, there is a specific subsystem (folder), that contains files that should be checkpatch'd. This subsystem is called the Staging subsystem, and can be found in the drivers/staging folder.

Obviously, to be able to use this tool you need to have setup an environment which is able to build the kernel from the source code. It is pretty easy to do so and will be explained in a later post.

If you have any questions, please find me on Freenode IRC as Levex in #fedora, #fedora-devel.