linux-kernel - Re: Number of bugs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080522151834.03f2790f@infradead.org>
Date:	Thu, 22 May 2008 15:18:34 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	Natalie Protasevich <protasnb@...il.com>,
	Bosko Radivojevic <bosko.radivojevic@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Number of bugs - statistics

On Thu, 22 May 2008 19:50:08 +0300
Adrian Bunk <bunk@...nel.org> wrote:

> > by various criteria: ALSA bugs
> > are numerous, which is not important for most enterprise server
> > users who would completely disregard this category, whereas desktop
> > users will probably concentrate on those more than any other.
> 
> The majority of machines running Linux most likely runs with ARM CPUs.

and on a 2.4 kernel, and with likely with some binary modules at that.
it's cool to brag about market share, but these boxes unfortunately
don't have any value for Linux development.

> 
> Show me any public source you want to use for getting serious data
> for this area.

You know, and I hate to say this, I'm getting a bit tired of your
attitude of just throwing up your arms at the problem and at the same
time trying to discredit anything and anybody who tries to improve the
situation. Really, it's not helping nor does it improve ANYTHING. 

I gave you real data before based on first hand experience from
maintainers. We now have crash data, and we have data from every place
in the kernel that dumps a backtrace. We track regressions and we can
show that we attack the majority of those very agressively, and Linus
has delayed releases for serious regressions. Just throwing your hands
in the air and saying "it's hard don't even try and I don't want you to
try" doesn't cut it.

Are we perfect? No. Can we do better? Absolutely. Should we try to do
better? YES PLEASE. Lets get constructive and try to make things better.

In the past, a few simple things improved the situation, such as
printk'ing the kernel version in the oops, as well as (longer back)
kksymoops. Or think of things like lockdep, or the pagealloc-debug
stuff. Going forward there are things we can do to improve things in the
kernel, even if you don't have hardware. We need to make the kernel
more selfdiagnosing. Detecting the problem, and if it's likely a
driver/hw interaction bug, sticking in a WARN_ON(). That's the sort of
thing even starting kernel developers can do to help improve the
quality even wihtout hardware access, because it helps us improve the
quality of bugreports, and it improves our ability to find patterns and
group duplicates into a top 10. 

Adrian, how about working on that sort of thing rather than keep saying
"impossible, we're doomed"... pretty please?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/