linux-kernel - Re: Slow DOWN, please!!!

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: <87od7pf1ne.fsf@basil.nowhere.org>
Date:	Fri, 02 May 2008 12:20:21 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Mariusz Kozlowski <m.kozlowski@...land.pl>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Dan Noe <dpn@...merica.net>, torvalds@...ux-foundation.org,
	rjw@...k.pl, davem@...emloft.net, linux-kernel@...r.kernel.org,
	jirislaby@...il.com
Subject: Re: Slow DOWN, please!!!

Mariusz Kozlowski <m.kozlowski@...land.pl> writes:
>
> Speaking of energy and time of a tester. I'd like to know where these resources
> should be directed from the arch point of view. Once I had a plan to buy as
> many arches as I could get and run a farm of test boxes 8-) But that's hard
> because of various reasons (money, time, room, energy). What arches need more
> attention? Which are forgotten? Which are going away? For example does buying
> an alphaserver DS 20 (hey - it's cheap) and running tests on it makes sense
> these days?

A lot of bugs are not architecture specific. Or when they are architecture
specific they only affect some specific machines in that architecture.
But really a lot of bugs should happen on most architectures. Just focussing
on lots of boxes is not necessarily productive.

My recommendation would be to concentrate on deeper testing (more coverage)
on the architectures you have.

A interestig project for example would be to play with the kernel gcov patch that
was recently reposted (I hope it makes mainline eventually). Apply that patch,
run all the test suites and tests you usually run on your favourite test box
and check how much of the code that is compiled into your kernel was really tested
using the coverage information Then think: what additional tests can you do to get 
more coverage?  Write tests then? Or just write descriptions on what is not tested 
and send them to the list, as a project for others looking to contribute to the 
kernel.

-Andi
--
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/