<div dir="auto">Thanks a ton, Valdis.</div><br><div class="gmail_quote"><div dir="ltr">On Wed 12 Sep, 2018, 11:23 PM , <<a href="mailto:valdis.kletnieks@vt.edu">valdis.kletnieks@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 12 Sep 2018 22:40:50 +0530, inventsekar said:<br>
<br>
> So, please suggest some subsystems or some small puedes of code, where i<br>
> can "dwell" sometimes and submit my first patch.<br>
<br>
0) subsystems? Anything under drivers/staging is fair game and certain to<br>
provide hours of amusement...<br>
<br>
1) Install sparse<br>
2) Get yourself a linux-next tree (so you don't submit fixes for already fixed stuff)<br>
<br>
$ git clone git://<a href="http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git" rel="noreferrer noreferrer" target="_blank">git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git</a><br>
$ cd linux<br>
$ git remote add linux-next git://<a href="http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git" rel="noreferrer noreferrer" target="_blank">git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git</a><br>
$ git fetch linux-next<br>
$ git fetch --tags linux-next<br>
<br>
If you want to update it later, do *not* use 'git pull'. Due to the way<br>
linux-next is rebased every day, doing that will result in a Lovecraftian horror....<br>
<br>
$ git remote update<br>
$ git checkout next-20180911 (or whatever)<br>
<br>
3) (optional) Add the following patch to the top level Makefile:<br>
<br>
diff --git a/Makefile b/Makefile<br>
index 9e71826f67d7..f28b2ab9c369 100644<br>
--- a/Makefile<br>
+++ b/Makefile<br>
@@ -434,6 +434,7 @@ KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \<br>
-Werror-implicit-function-declaration \<br>
-Wno-format-security \<br>
-std=gnu89<br>
+KBUILD_CFLAGS += -Wimplicit-fallthrough=2 -Wvla<br>
KBUILD_CPPFLAGS := -D__KERNEL__<br>
KBUILD_AFLAGS_KERNEL :=<br>
KBUILD_CFLAGS_KERNEL :=<br>
<br>
4) Figure out why I said (3) (There's an actual reason for that)<br>
<br>
5) Build your kernel, running sparse on the code before compiling with extra<br>
warnings:<br>
<br>
$ make C=2 W=1 |& tee build.output<br>
<br>
6) Start looking at the output. Note however that sparse and gcc<br>
sometimes throw warnings for perfectly good code, so do *not*<br>
submit random "shut up warning" patches. Verify the warning is<br>
in fact correct, *then* submit the patch.<br>
<br>
If you get ambitious, find out what Coverty and Trinity are, and other similar<br>
tools. If you use Trinity, remember to always mount a scratch monkey. :)<br>
<br>
</blockquote></div>