I will start this blog post with a wide smile on my face, mainly because of the appreciation to my work provided by the Kernel community. I would like to say “Thank you” for boosting my morale. 😀 However, there were many challenges which I had to face while eliminating the missing-prototypes warning. I would be elaborating on a few in this blog post.
a) Architecture Specific Prototypes
It is very common to find symbols in the kernel which have their prototype definition in architecture specific headers. So, in such cases, we should move it to an appropriate header file (an architecture-independent header file). The reason to do this is the fact that function definition stays in all kernel build (regardless of architecture) while the prototype definition becomes available only when re-build in that particular architecture.
The pattern is likely to be similar for __weak symbols. We don’t want to prototype them in arch-specific headers but only in some general header associated with the source file that defines the architecture-independent stub version.
b) Functions used in init/main.c
The file init/main.c calls “init” functions from all over the kernel, and doesn’t tend to properly use headers for them. Therefore, it is difficult to find an appropriate header file to move the prototype into.
There are two general strategies to solve this issue; either init/main.c has to include a hundred different headers that define only one function it needs (along with piles of other functions, in some cases), or there should be a dedicated header. The latter seems to be a better option. Therefore, creating an include/linux/initmain.h ,and putting all the prototypes for the unprototyped extern’d init functions from init/main.c in there is a right choice. Then init/main can just include that header file, so can every .c file defining one of those init functions.
I will keep you all posted about the other interesting things which I come across while eliminating the warnings. Till then, bye 🙂