linux-kernel - Re: Separate arch patching (Re: [patch-mm 06/25] clockevents: Fix resume logic)

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: <1182020654.8176.398.camel@chaos>
Date:	Sat, 16 Jun 2007 21:04:14 +0200
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Oleg Verych <olecom@...wer.upol.cz>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Andi Kleen <ak@...e.de>,
	Chris Wright <chrisw@...s-sol.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Separate arch patching (Re: [patch-mm 06/25] clockevents: Fix
	resume logic)

Oleg,

On Sat, 2007-06-16 at 20:51 +0200, Oleg Verych wrote:
> >  arch/arm/plat-omap/timer32k.c     |    2 +
> 
> Testers and users are most likely to run one particular arch on
> one particular test bench. If individual patches are arch
> separated, i think bisecting will be a little bit easier.

No it is not. See below.

> Thus, i would like to propose separate arch patching (x86_64/i386 mainly).

This change adds an enum entry in a generic header file. _ALL_ users of
clock events have a switch(this_changed_enum) in the set_mode()
function. _ALL_ of them will spit warnings and some of them will even
break, when the fix up is not done in one go.

> Is it possible to do that? (And even set such check in ``checkpatch''?)

It's possible, but results in an commit which will affect bisecting. I'm
not going to send a patch which knowingly breaks bisecting either at
compile or at run time.

> You would say, why? Because current kbuild/kconfig support of builds
> for whole tree.
> 
> That's because to make download, build, test and debug particular arch
> more easily, i'm trying to re-think and re-do some kbuild parts. With
> minimum set of files, downloaded with git one can spend less
> time/bandwidth for starting testing.

Oh, well. That's going to be an interesting feature for git and the
result will be published kernel trees with a total delta of 40MB against
mainline, because someone tweaked the stuff in a way that it contains
only the relevant files for a particular sub architecture. Embedded
folks do this already and it makes it extremely hard to do efficient
trouble shooting on such crippled trees. No thanks.

If we would still have 9600 Baud modem connections I would understand
that, but git is really effective since packing was added, so this
argument is more or less an academic exercise.

	tglx

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