Re: [patch 0/17] Series to introduce WARN()... a WARN_ON() variant that takes printk arguments

Ingo Molnar
2008-07-09T12:14:18Z

* Andrew Morton <akpm@linux-foundation.org> wrote:

> > Note that this situation is special: this is a patchset that has
> > virtually no functionality side-effects, and hence can be done 100%
> > correctly, i thought the atomic step was the right approach.
> >
> > For anything semantically meaningful i too would do the spread-out
> > gradual approach (and i'm presently doing that for a number of
> > topics).
> >
> > But if you'd like to do this the spread-out way then sure, and i
> > will drop this tree. ( if you do that then please import the commits
> > from tip/core/warn-API, i fixed a couple of of typos in the commit
> > messages and did some merging and extensions as well. The tree also
> > passed a fair amount of testing meanwhile as well. )
> >
> > Anyway, your call.
>
> Well I haven't got onto processing these patches in detail yet. An
> open questions is why the damn thing was resubmitted from scratch when
> I've already merged it and fixed various rejects and had to fix
> several bugs in it. Do those rejects need to be re-fixed? Were my
> bugfixes folded back? I haven't looked yet. I'll need to generate the
> incremental diff and see what was done.
>
> But if what you've merged was against mainline then it isn't terribly
> useful.

i cross-ported it from the linux-next base to -git base and the conflict
fallout was minimal, well below 5% or so. I.e. the patches change
long-existent warnings that have not changed in linux-next either.

About 30% of the changes in this patchset affect subsystems that i
co-maintain, still tip/core/warn-API did a pure, conflict-free git-merge
when it was applied ontop of all these subsystem trees:

commit 99eb83efbe2e3c12d26be22a032495ccddb36a2c
Merge: de67579... c2e0195...
Author: Ingo Molnar <mingo@elte.hu>
Date: Wed Jul 9 12:14:48 2008 +0200

Merge branch 'core/warn-API'

Hence my suggestion that this should be maintained and forward ported to
the end of the merge window, in a separate, standalone tree that is -git
based.

Anyway, no strong feelings, it's your call.

Ingo