On Tue, Aug 8, 2017 at 11:48 AM <valdis.kletni...@vt.edu> wrote: > On Tue, 08 Aug 2017 05:36:34 -0000, Amit Kumar said: > > > When I compile arm64/defconfig kernel with W=1, build emits a lot of > > warnings. When patch is required to be "build clean" then why warnings > are > > there? I want to understand. > > The warnings that come out with the default W=0 are by an large indicative > of code that's syntactically correct, but probably *do* have unintended > semantics, so those should be fixed up properly. > > The problem with W=1 is that although W=1 will generate a lot of warnings, > a > lot of them are things we don't actually want to go out of our way to fix. > That's because W=1 turns on a *lot* of nitpicking "did you really mean to > do > that?" warnings - and in kernel code, yes, we often really *did* mean to do > that. > > Now, *some* of them do indeed call for fixing. But make sure that you're > fixing an *actual* problem, where the warning indicates an actual bug. All > too often, we get patches that just shut the warning up, and don't fix a > bug - or even worse, introduce bugs where there weren't any before. > > There's also something to be said for fixing warnings that are in .h files, > because they end up emitting warnings for multiple .c files. A while back, > I submitted a short series of "low hanging fruit" patches against the > drivers/staging/lustre tree - the big win was a one-liner that silenced a > macro in all 231 places it was used. But again - make sure the patch is > an improvement, and not just papering over an issue. >
Thank you for reply. I have noticed that there are mostly missing prototype, variable set but not used, macro related and dtc warning unit not used in device tree. As I navigate source, I'll understand which I should hunt for. Last but not least, according to your suggestion, I'll hunt these warnings when I create patch. I'll not create patch to get rid of warnings. Regards, Amit Kumar
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies