linux-kernel - Re: Linux 2.6.24

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: <4799D770.2070203@cateee.net>
Date:	Fri, 25 Jan 2008 13:34:56 +0100
From:	"Giacomo A. Catenazzi" <cate@...eee.net>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	Valdis.Kletnieks@...edu,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.24

Rafael J. Wysocki wrote:
> On Friday, 25 of January 2008, Valdis.Kletnieks@...edu wrote:
>> On Fri, 25 Jan 2008 10:10:11 +0100, "Giacomo A. Catenazzi" said:
>>
>>> - you will introduce a new step on git management:
>>>    Every changeset is compile-tested before going out to the world.
>>>    I think this can be done automatically, and I think that one or
>>>    two configurations are enough to find most of the problems.
>> It's true that a compile on x86 and a compile on PowerPC
> 
> Please add IA-64 and ARM at the very least.

My point was about "obvious" errors, and I really think that one
or two configuration will found most of these, doing in an
automatic way, and without delay the process.
Anyway more test are surely better.
BTW, IIRC there are already few "testing farms" which tests
automatically  a lot of environment and configuration (IIRC,
also run time tests).

>> should flush out 
>> most of the truly stupid mistakes, but those are usually found and fixed
>> literally within hours.  Anyhow, the proper time for test compiles is *before*
>> it goes into the git trees at all - it should have been tested before it
>> gets sent to a maintainer for inclusion.

few hours, but a lot of changeset will broke bisect (few doc tell
us how to continue bisecting on compile errors).
But I agree with you.

> 
> That's correct, but I'm not sure how to enforce it.

As usual, "One level more indirections" ;-) . Along a spamfilter,
we (or Linus) need a patch filter.

ciao
	cate

PS: I don't want to be pessimistic. I only want to raise the problem,
to see if it is possible to improve testing environment without
affecting the development of Linux.
--
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/