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: <20080512092718.GG16284@fluff.org.uk>
Date:	Mon, 12 May 2008 10:27:19 +0100
From:	Ben Dooks <ben@...ff.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Mariusz Kozlowski <m.kozlowski@...land.pl>, 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!!!

On Wed, Apr 30, 2008 at 04:11:30PM -0700, Andrew Morton wrote:
> On Thu, 1 May 2008 00:53:31 +0200
> Mariusz Kozlowski <m.kozlowski@...land.pl> wrote:
> 
> > Hello,
> > 
> > > > Perhaps we should be clear and simple about what potential testers 
> > > > should be running at any given point in time.  With -mm, linux-next, 
> > > > linux-2.6, etc, as a newcomer I find it difficult to know where my 
> > > > testing time and energy is best directed.
> > 
> > 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?
> > 
> 
> gee.
> 
> I think to a large extent this problem solves itself - the "more important"
> architectures have more people using them, so they get more testing and
> more immediate testing.
> 
> However there are gaps.  I'd say that arm is one of the more important
> architectures, but many people who are interested in arm tend to shy away
> from bleeding-edge kernels for various reasons.  Mainly because they have
> real products to get out the door, rather than dinking around with mainline
> kernel developement.  So testing bleeding-edge on some arm systems would be
> good, I expect.

As both personally, and the policy of my employer we try and ensure we
can offer our customers at-least the previous 'stable' kernel release
and ensure that our development process tracks the kernel -rcX
candidates. We also run an autobuilder[1] which runs all -git releases
through an automated build (no auto-test yet) to ensure that we can
detect any build or configuration errors in the releases. 

ARM is a fast moving area due to the amount of sillicon vendors out
there who seem intent on doing their own thing, and often forking
hardware blocks they use during differing development branches. I
am currently looking at merging support for the S3C6400 (new) and
finishing S3C2443 (similar to 6400) and the S3C24A0... this means
that I have a lot of code to look through before each release and
having a stall will just keep the backlog building, making my job
a lot more difficult.


[1] http://armlinux.simtec.co.uk/kautobuild/

-- 
Ben (ben@...ff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'
--
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/