Re: The sheer number of sparse warnings in the kernel

[Peter Hurley <peter@hurleysoftware.com>]

On 02/26/2014 07:11 PM, H. Peter Anvin wrote:
> On 02/26/2014 03:28 PM, Greg KH wrote:
>>>
>>> What do we need to do to actually make our tools be able to do work for
>>> us?  Newbie projects to clean up?  Trying to get the larger Linux
>>> companies to put resources on it?
>>
>> It's not the easiest "newbie" project as usually the first reflex to
>> "just cast it away" is wrong for a lot of sparse warnings.  I know this
>> from people trying to fix up the sparse warnings in drivers/staging/
>>
>
> I have seen this phenomenon, too.  I also see a bunch of sparse warnings
> which are clearly bogus, for example complaining about sizeof(bool) when
> in bits like:
>
> 		__this_cpu_write(swallow_nmi, false);
>
> So getting this to the point where it is genuinely useful and can be
> made a ubiquitous part of the Linux development process is going to take
> more work and probably involve improvements to sparse so we can indicate
> in the kernel sources when something is okay or removing completely
> bogus warnings, and so on.
>
> The bigger question, again, is what do we need to do to make this
> happen, assuming it is worth doing?  We certainly have had bugs,
> including security holes, which sparse would have caught.  At the same
> time, this kind of work tends to not be the kind that attract the top
> hackers, unfortunately, as it is not "fun".

Well there was that "should we do a bug-fix-only 4.0 release?" message
from Linus back at the 3.12 release.

Or do like Geert does with the build message regressions/fixes. I always scan
that to make sure none of my work is in it :)  (And that could be chunked
up by maintainer).

Just a thought.

Regards,
Peter Hurley