Making the Kernel free of “missing-prototypes”

As I mentioned in my last blog-post, I began working on my project “Tree-wide warning fixes and static analysis enhancements”. I started with the task of elimination of all instances of the warning:

warning: no previous prototype for 'name_of_symbol' [-Wmissing-prototypes]

The kernel build log has many such occurrences. This warning is a non-default GCC warning. So, the question arises:

question How do you generate these warnings?

The answer is simple. You just need to make a little change to your Makefile i.e. add -Wmissing-prototypes to KBUILD_CFLAGS in the top-level Makefile and do a build with defconfig or allyesconfig (If -Wmissing-prototypes is specified, it tells the compiler to detect global functions that are defined without a previous prototype declaration).
Voila!, you will notice a pile of new warnings about symbols with no prototype declarations. Alternatively, you can build the kernel with W=1.

One more thing which is important while building a kernel, is to save the log (This will help you to deal with the log conveniently). To do this, use the following command:

make 2>&1 | tee /path/to/build.log

question Why this warning?

These warnings are particularly useful to remove unused code from the kernel and thus making the kernel much smaller for everyone. These also help to detect any ambiguity related to prototype type mismatch which is a real bug and can even break the kernel build.

question How to eliminate it?

There are various ways of removing this warning. Umm, before that we need to learn one more thing, which is to find the occurrences of a particular symbol. This is easily done by the powerful tool GIT, the command being:

git grep -w <symbol-name>

Alternatively, you can find a header file containing that symbol using:

git grep -w <symbol-name> -- '*.h'

Then for each symbol, check if the symbol is used elsewhere in the kernel, and apply the appropriate fix:

– If it isn’t used anywhere else, mark it “static”.
– If it is defined and not used anywhere else, remove the function definition.
– If it is used elsewhere and has a prototype in a header file, include that header file in the source file.
– If it is used elsewhere and doesn’t have a prototype in a header file, typically because the callers elsewhere use an explicit prototype in a .c file, then you should either find an appropriate header file to put the prototype in, create one, or as a last resort add a prototype right above the definition to silence the warning.

After making these changes, you submit the edited portion of the file(s) in the form of a patch to appropriate recipients as indicated by get_maintainer.pl script. This script informs you about whom the patches have to be send to and why. To learn more about sending patches to the kernel’s mailing list, you can take the help of this easy-to-follow tutorial Linux Kernel: Submit a patch.

For now, I plan to eliminate *all* these instances by the next time I write a blog-post 😀 and move on to test these warnings on different architectures.
I will keep you posted about more such interesting things which I will keep learning during my internship. Till then, good-bye 🙂

Rashika

Open Source World: An Odyssey of discovery

Have you ever found yourself facing a wall of hesitation because you don’t know how to effectively start your intended blog post? Do you find yourself staring at the computer screen for several hours mainly because you are clueless on how to connect all your ideas into a cohesive start?

Well, I do feel the same, so, I thought why not begin with this 😛

Let me introduce myself first. I am Rashika Kheria, a CS Undergraduate student. Umm, a better introduction would be Rashika Kheria, OPW Intern working on Linux Kernel. Doesn’t it sound great? 😀 Now, you must be wondering that how all of a sudden, I became an OPW intern, well, the credit goes to GNOME‘s OPW program, the supportive and the helpful Linux community and a little bit to me ( 😛 ).

I was always intrigued to work and contribute to FOSS projects, but I never got an opportunity to actually dive into it (courtesy: my laziness) and FINALLY, I got to hear about the OPW December-March program, so I thought,”let’s give it a whirl”. I surfed the web and tried to find everything about it. I went through all the participating organizations, the projects offered by them and finally decided to work for the Linux community.

When I started with the application period on October 1st, I had no idea about what I was going to do. But eventually, to my surprise, it turned out to be very enjoyable, interesting, addictive and full of learning experience. My routine became wake up, change the driver’s code, submit patches, get the reviews, modify the patches and sleep (The worst I can tell is that I started dreaming about patches 😛 ). I did not realize when the application period got over and I started waiting for the results.

The results were coming on November 25, 12:30 a.m. (Technically, November 26 in India). I was trying to avoid thinking about it to lessen my anxiety. But my attempt finally failed at 8:00 p.m. and I stopped studying for my University exam (scheduled on November 27 😛 ). I started refreshing the page on which the result was going to be announced from 12:15 a.m. and as soon as it came out, I shouted with glee, “Yes!! My name is there. I am selected as an OPW intern”. This feeling was so awesome 😀 . This was followed by a series of mails instructing the selected interns about what to do next. And this attempt of writing a blog post is one of those 😛

Right now, I am excited to work on my project “Tree-wide warning fixes and static analysis enhancements” and officially start with my internship. I will keep you all updated about the exciting new things that I am going to learn in this Odyssey 🙂

Rashika