linux-kernel - Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

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]

Date:	Sun, 17 Jun 2007 16:24:30 +0200
From:	Oleg Verych <olecom@...wer.upol.cz>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Adrian Bunk <bunk@...sta.de>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	Diego Calleja <diegocg@...il.com>,
	Chuck Ebbert <cebbert@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

On Sun, Jun 17, 2007 at 02:13:39PM +0200, Rafael J. Wysocki wrote:
> On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
[]
> > It's OK _only_ in case of unknown, hard to find *hardware* bugs.
> > 
> > If you think it's "a good thing" for bad, untested by developer
> > code, then something is completely wrong.
> 
> Oh, I've just fixed two purely software bugs pointed out by binary searching
> in the code that I'm sure has been tested, not only by its developers, but the
> bugs only showed up in my configuration (on one out of four test boxes).
> 
> There are so many different kernel configurations possible that there's no way
> a developer can test them all.

With current state of affairs it's not only hard for developers, but
and for users: <20070221220520.GA20659@...select.com>,
              <20070429230037.95120@....net>

I'm trying to re-do some kbuild stuff, but i'm getting rather offensive
answers :( <1182020654.8176.398.camel@...os>

(Even if i'm academic with free Internet, i doubt i even tried to
think to improve something, if i didn't have one, because i wouldn't knew
huge lkml traffic, problems, etc.)

Maybe i'm wrong. But reducing amount of traffic/files and ease of
(re-)configuration are not last things to be done for better testing.
All for speed of getting and compiling kernel. Latter for avoiding
bugs and noise due to inconsistent build configuration.

Finally again, bug-reporting and tracking tools, i've tried to discuss
are major problems out there I think it's plain easy and deal with. One
more example:

    <handler.s.C.117647526113388.transcript@...s.debian.org>
    Xref: news.gmane.org gmane.linux.debian.devel.kernel:28095
    <http://permalink.gmane.org/gmane.linux.debian.devel.kernel/28095>
____
-
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/