linux-kernel - Re: [PATCH 5/6] x86: Merge hardirq.h

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: <49770808.2030909@kernel.org>
Date:	Wed, 21 Jan 2009 20:33:28 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Brian Gerst <brgerst@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/6] x86: Merge hardirq.h

Hello, Ingo.

Ingo Molnar wrote:
> While this patch was indeed broken, generally for -tip patches we are very 
> permissive and do not require testing 4 .config variants: compile testing 
> on the bit width x86 variant that is being modified is enough. If both 
> variant are modified (as in this case) then compiling the 32-bit and 
> 64-bit defconfig is enough.
> 
> If some build failure slips through it will be handled by automated 
> testing facilities (such as -tip's testing) - it really does not scale if 
> we expect developers to build kernels they dont use (and dont care about 
> nearly as much as about their primary config).
> 
> This lowers the bar of entry to developers who submit their patches from 
> low-powered hardware and simply dont have the means to do wide build 
> testing. The many .config variations are not really the developer's fault 
> but our collective fault. Developers should spend their time thinking 
> about patches, not waiting for the nth kernel build to finish.

I just sent a patch with a lot of compile breakages so I'm feeling
quite embarrassed here but when the patch is touching this low in arch
code, I don't think small four configuration build isn't too much
before sending out a patchset.  With two quad core machines and ram
disk configured, it just doesn't take that much of time (which BTW
doesn't cost that much these days).  With my typical test config,
whole build takes about 80 to 90 seconds.  Four times that is still
under ten minutes.

Anyways, it's a balancing act.  Four small builds don't sound like too
much to me.  Hey, if you're okay with it.  :-)

Thanks.

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