On Tue, 13 Oct 2020, Greg Kroah-Hartman wrote: > On Tue, Oct 13, 2020 at 09:16:27AM +0200, Lukas Bulwahn wrote: > > Some others actually believe that the use of static analysis tools > > increase software quality and ONLY IF a static analysis tool is used, a > > specific level of software quality is achieved and they want to prove > > that the software reaches a certain level that way. (I do not > > understand that argument but some have been repeating it quite often > > around me. This argument seems to come from a specific interpretation of > > safety standards that claim to have methods to predict the absense of > > bugs up to a certain confidence.) > > So do those others also audit the static analysis tools to ensure that > they actually work as they "think" they do? If not, then their > requirement is pretty pointless :) > Yes, they do audit the tools, but those audits and why that proves the absense of a bug class is yet a completely different story... > > I am doing it for the fun and learning about tools, and I am not such a > > believer but those others would be forced by their beliefs until they > > understand what static analysis tools and their janitors really already > > contribute to the kernel development and where the real gaps might be. > > > > I hope that helps to get a bit of the motivation. Consider us > > kernel newbies :) > > Watch out, sending patches to subsystems to "fix" issues that really > are not real problems is a sure way to get your patches rejected and > make maintainers grumpy. > > I recommend starting out with code that we all "know" needs help, in > drivers/staging/ for stuff like this, so you can learn the process > better, as well as start to understand the limitations of your tools > better. > > good luck! > Thanks for the advice. We will need to learn about the limitations and what is worth a patch and what is not and we will need luck on the way learning that. Lukas
