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

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

[Arjan van de Ven]

Hi,

This patch series introduces WARN(), which is a WARN_ON() variant that
takes printk() like arguments. This was done after both akpm and I hit
several cases where this would have been useful; in addition, with
WARN(), we put the printk string inside the -----[ cut here ]-----
section, making it more likely that users (and tools like kerneloops)
pick up the message in addition to just the bare WARNING.

The first few patches have been in -mm for a long time; the later ones
are newer and introduce more users of WARN().

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

[Arjan van de Ven]

Hi,

This patch series introduces WARN(), which is a WARN_ON() variant that
takes printk() like arguments. This was done after both akpm and I hit
several cases where this would have been useful; in addition, with
WARN(), we put the printk string inside the -----[ cut here ]-----
section, making it more likely that users (and tools like kerneloops)
pick up the message in addition to just the bare WARNING.

The first few patches have been in -mm for a long time; the later ones
are newer and introduce more users of WARN().

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

[Ingo Molnar]

* Arjan van de Ven <arjan@infradead.org> wrote:

> Hi,
> 
> This patch series introduces WARN(), which is a WARN_ON() variant that 
> takes printk() like arguments. This was done after both akpm and I hit 
> several cases where this would have been useful; in addition, with 
> WARN(), we put the printk string inside the -----[ cut here ]----- 
> section, making it more likely that users (and tools like kerneloops) 
> pick up the message in addition to just the bare WARNING.
> 
> The first few patches have been in -mm for a long time; the later ones 
> are newer and introduce more users of WARN().

i've created a new -git based topic branch in tip/core/warn-API and 
picked up your patches:

 Arjan van de Ven (16):
      full tree: clear the WARN() namespace
      core: add a WARN() macro that acts like WARN_ON()+printk
      kobject: introduce WARN() usage in the kobject code
      irq: use WARN() in kernel/irq/manage.c
      mm: use WARN() in mm/vmalloc.c
      lockdep: use WARN() in kernel/lockdep.c
      irq: use WARN() in kernel/irq/chip.c
      x86: use WARN() in arch/x86/mm/ioremap.c
      x86: use WARN() in arch/x86/mm/pageattr.c
      x86: use WARN() in arch/x86/kernel
      block: use WARN() in block/
      driver core: use WARN() in drivers/base/
      core libs: use WARN() in lib/
      fs: use WARN() in fs/
      sysfs: use WARN() in fs/sysfs
      procfs: use WARN() in fs/proc/

it can be picked up via:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git core/warn-API

( Note, i added a few more tree-wide namespace preparation fixes to the 
  first patch - a few more came in since you first prepared this patch i 
  guess. )

	Ingo

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

[Andrew Morton]

On Wed, 9 Jul 2008 12:13:48 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> > Hi,
> > 
> > This patch series introduces WARN(), which is a WARN_ON() variant that 
> > takes printk() like arguments. This was done after both akpm and I hit 
> > several cases where this would have been useful; in addition, with 
> > WARN(), we put the printk string inside the -----[ cut here ]----- 
> > section, making it more likely that users (and tools like kerneloops) 
> > pick up the message in addition to just the bare WARNING.
> > 
> > The first few patches have been in -mm for a long time; the later ones 
> > are newer and introduce more users of WARN().
> 
> i've created a new -git based topic branch in tip/core/warn-API and 
> picked up your patches:

um, why?

If you merge this into linux-next then it will trash already-merged patches
in -mm and, more particularly, it will trash other trees which you aren't
looking at, causing Stephen problems.

The way to merge this code is to get the base patches into mainline and
then trickle the dependent patches into subsystem trees, or direct into
mainline after the subsystem trees have merged, and with suitable acks.

You aren't set up to do that?

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

[Ingo Molnar]

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

> > > The first few patches have been in -mm for a long time; the later 
> > > ones are newer and introduce more users of WARN().
> > 
> > i've created a new -git based topic branch in tip/core/warn-API and 
> > picked up your patches:
> 
> um, why?
> 
> If you merge this into linux-next then it will trash already-merged 
> patches in -mm and, more particularly, it will trash other trees which 
> you aren't looking at, causing Stephen problems.

no, i didnt plan to push this towards linux-next - given the broad 
consensus and given the wide spread of the changes.

I wanted to wait with this until the end of the merge window and keep it 
tested and merged up nicely. I.e. zero maintenance overhead to 
subsystems.

> The way to merge this code is to get the base patches into mainline 
> and then trickle the dependent patches into subsystem trees, or direct 
> into mainline after the subsystem trees have merged, and with suitable 
> acks.
> 
> You aren't set up to do that?

i think it's better to just go through the merge window i believe, and 
then do this atomically in one correct and tested step, when all 
subsystem trees are at their minimum size and there's virtually no 
collisions.

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.

	Ingo

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

[Andrew Morton]

On Wed, 9 Jul 2008 13:37:03 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > > > The first few patches have been in -mm for a long time; the later 
> > > > ones are newer and introduce more users of WARN().
> > > 
> > > i've created a new -git based topic branch in tip/core/warn-API and 
> > > picked up your patches:
> > 
> > um, why?
> > 
> > If you merge this into linux-next then it will trash already-merged 
> > patches in -mm and, more particularly, it will trash other trees which 
> > you aren't looking at, causing Stephen problems.
> 
> no, i didnt plan to push this towards linux-next - given the broad 
> consensus and given the wide spread of the changes.

Well, there was no way for me (or, I believe, Arjan or anyone else) to have
worked this out from your reply.

> I wanted to wait with this until the end of the merge window and keep it 
> tested and merged up nicely. I.e. zero maintenance overhead to 
> subsystems.

That's an option.  That's why I will cc the relevant subsystem maintainers
on the commits, and will collect and maintain the acked-by's.

> > The way to merge this code is to get the base patches into mainline 
> > and then trickle the dependent patches into subsystem trees, or direct 
> > into mainline after the subsystem trees have merged, and with suitable 
> > acks.
> > 
> > You aren't set up to do that?
> 
> i think it's better to just go through the merge window i believe, and 
> then do this atomically in one correct and tested step, when all 
> subsystem trees are at their minimum size and there's virtually no 
> collisions.

Probably.

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

Hopefully this sort of thing won't happen as much once I get -mm into
linx-next.  Soon...

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

[Ingo Molnar]

* 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

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

[Arjan van de Ven]

On Wed, 9 Jul 2008 04:46:13 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> 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.

I started with the version in -mm (and had to do one reject fix against
-next) with folding the 2 -fix's into it.

-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org