Messages in this thread | | | Date | Wed, 26 Feb 2014 20:52:03 -0500 | From | Peter Hurley <> | Subject | Re: The sheer number of sparse warnings in the kernel |
| |
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
| |