Messages in this thread | | | Subject | Re: Separate arch patching (Re: [patch-mm 06/25] clockevents: Fix resume logic) | From | Thomas Gleixner <> | Date | Sat, 16 Jun 2007 21:04:14 +0200 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |