Fixing Warnings

Fixing Warnings

[Richard Purdie]

We need to ensure we don't overlap with the warning message fixing work.
I've created:

https://wiki.yoctoproject.org/wiki/Warning_Fixing

which has a list of the remaining warnings I know about and has an
indication of who (if anyone) is addressing them. Please check there
before working on any given warning message.

The good news is we're down to about 115 of them for world assuming the
pending patches merge. 

I'm tempted to turn off the exec_prefix cross linkage warnings in the
release branch for this release since the fixes for those could be too
invasive to take the risk on at this point in the release cycle and most
users probably don't need to see those warnings. Those warnings should
be treated as the lowest priority.

Cheers,

Richard

Fixing warnings

[srishti sharma]

Hey,

Can we fix two warnings in a single patch ?


Regards,
Srishti

Fixing warnings

[valdis.kletnieks at vt.edu]

On Sat, 03 Jun 2017 02:47:55 +0530, srishti sharma said:
> Can we fix two warnings in a single patch ?

Depends what the two warnings are.  If they're two actual kernel warning
messages, probably best off doing 2 patches.

If it's 2 complaints from checkpatch, it depends.  If they're two or more
instances of the same style issue (for instance, "blank needed here"), do
them all in the same patch.  If it's two different style warnings (say,
missing blanks in one place, and too-long lines in another), that's 2 patches.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170602/eff6d754/attachment.bin 

Fixing warnings

[srishti sharma]

Thanks a lot !

Regards
Srishti

On Sat, Jun 3, 2017 at 2:57 AM,  <valdis.kletnieks@vt.edu> wrote:
> On Sat, 03 Jun 2017 02:47:55 +0530, srishti sharma said:
>> Can we fix two warnings in a single patch ?
>
> Depends what the two warnings are.  If they're two actual kernel warning
> messages, probably best off doing 2 patches.
>
> If it's 2 complaints from checkpatch, it depends.  If they're two or more
> instances of the same style issue (for instance, "blank needed here"), do
> them all in the same patch.  If it's two different style warnings (say,
> missing blanks in one place, and too-long lines in another), that's 2 patches.
>

Fixing warnings

[valdis.kletnieks at vt.edu]

On Sat, 03 Jun 2017 02:59:56 +0530, srishti sharma said:
> Thanks a lot !

Also, large parts of the kernel have maintainers who do *not* want to
see checkpatch fixes, because there's 2 basic possibilities:

1) The code is being actively worked on by others as well, in which case
your patches can cause merge conflicts for no real benefit.

2) The code isn't being worked on, which means your patches (if incorrect)
may cause code instability for no real benefit.

End result is that most of the kernel only wants style fixups as part of
a series of actual code patches - if you're fixing bugs or redoing an
algorithm, then send style patches as part of the series.

The rules are different for anything under drivers/staging - all code in there
is assumed to be manure that needs fixing, so feel free to fix it. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170602/fd366067/attachment.bin 

Fixing warnings

[srishti sharma]

Thank you so much for the advice :)

Regards,
Srishti

On Sat, Jun 3, 2017 at 3:26 AM,  <valdis.kletnieks@vt.edu> wrote:
> On Sat, 03 Jun 2017 02:59:56 +0530, srishti sharma said:
>> Thanks a lot !
>
> Also, large parts of the kernel have maintainers who do *not* want to
> see checkpatch fixes, because there's 2 basic possibilities:
>
> 1) The code is being actively worked on by others as well, in which case
> your patches can cause merge conflicts for no real benefit.
>
> 2) The code isn't being worked on, which means your patches (if incorrect)
> may cause code instability for no real benefit.
>
> End result is that most of the kernel only wants style fixups as part of
> a series of actual code patches - if you're fixing bugs or redoing an
> algorithm, then send style patches as part of the series.
>
> The rules are different for anything under drivers/staging - all code in there
> is assumed to be manure that needs fixing, so feel free to fix it. :)
>