Re: Separate arch patching (Re: [patch-mm 06/25] clockevents: Fixresume logic)

[Thomas Gleixner]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/