linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	linux-kernel@vger.kernel.org, linux-safety@lists.elisa.tech,
	linux-usb@vger.kernel.org
Subject: Re: [linux-safety] [PATCH] usb: host: ehci-sched: add comment about find_tt() not returning error
Date: Tue, 13 Oct 2020 09:35:24 +0200	[thread overview]
Message-ID: <20201013073524.GA1674118@kroah.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2010130850410.14590@felia>

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 :)

> 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!

greg k-h

  reply	other threads:[~2020-10-13  7:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-11 20:50 [PATCH] usb: host: ehci-sched: add comment about find_tt() not returning error Sudip Mukherjee
2020-10-12  0:27 ` Alan Stern
2020-10-12 14:11 ` [linux-safety] " Lukas Bulwahn
2020-10-12 14:57   ` Alan Stern
2020-10-12 15:10     ` Lukas Bulwahn
2020-10-12 15:18       ` Greg Kroah-Hartman
2020-10-12 18:25         ` Lukas Bulwahn
2020-10-13  5:23           ` Greg Kroah-Hartman
2020-10-13  5:37             ` Lukas Bulwahn
2020-10-13  6:36               ` Greg Kroah-Hartman
2020-10-13  7:16                 ` Lukas Bulwahn
2020-10-13  7:35                   ` Greg Kroah-Hartman [this message]
2020-10-13  8:02                     ` Lukas Bulwahn
2020-10-13  8:24               ` Sudip Mukherjee
2020-10-13  8:36                 ` Lukas Bulwahn
2020-10-12 16:00       ` Alan Stern
2020-10-12 18:17         ` Lukas Bulwahn
2020-10-13  5:21           ` Greg Kroah-Hartman
2020-10-13  5:41             ` Lukas Bulwahn
2020-10-12 15:24   ` Sudip Mukherjee
2020-10-12 18:49     ` Lukas Bulwahn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201013073524.GA1674118@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-safety@lists.elisa.tech \
    --cc=linux-usb@vger.kernel.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=sudipm.mukherjee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).