Kernel build warnings

[Amit Kumar]

On Tue, Aug 8, 2017 at 11:48 AM <valdis.kletnieks at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170808/fe147ec6/attachment.html