Date:	Mon, 27 Sep 2010 12:44:19 -0000
From:	Thomas Gleixner <tglx@...utronix.de>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-arch@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Julia Lawall <julia@...u.dk>
Subject: [patch 00/19] genirq: Cleanup and irq_chip functions overhaul

I'm working on a large scale overhaul of the generic irq code. One of
the goals is to sanitize the sparse irq code, which is pretty much
impossible right now as there are too many sites accessing and
fiddling with irq_desc directly (And I'm not even talking about the
__do_IRQ() cadavers).

Some of these accesses have legacy reasons, some grew out of laziness
and some are just due to shortcomings in the generic code, which need
to be addressed.

The long term plan is to make irq desc private to the generic irq code
to allow freeing of unused irq descriptors, moving the irq descriptor
to a different node when the irq affinity changes and to allow
internal optimizations.

Following problems need to be addressed:

 - irq chips, which need to access irq_desc->chip_data, msi_desc etc.
  
    This is a problem already today when sparse irq is enabled. We
    need to lookup the irq desc for the interrupt to gain access to
    the data. With sparse this requires a redundant radix tree lookup
    as the core code already has a pointer to irq desc when the low
    level chip functions are called.

    It was proposed to simply hand down irq_desc in the functions, but
    low level code should not know about the details of irq_desc at
    all.

    The solution to this is to switch to a new set of irq_chip
    functions which have as single argument a pointer to a new
    irq_data structure which holds the irq number, desc->handler_data,
    desc->chip_data, desc->msi_desc, desc->affinity and a reference to
    the chip itself. The structure is embedded into irq_desc for now,
    but that's going to change, when the first cleanup round is done.

    AFAICT, that should be sufficient to satisfy the requirements of
    all low level implementations.

    For a transition phase both the old and the new functions are
    handled with wrappers in the core code.

    The new functions are implemented in:
    [Patch 3/19] genirq: Provide advanced irq chip functions
    
    Note: chip->end() will be dropped as it is just related to the old
    __do_IRQ() function and not used in the flow based handler code.


 - direct access to irq desc in architecture / drivers code.

    That's mostly related to sparse, irq affinity settings,
    show_interrupts() and fixup of irqs on cpu hot unplug.

    sparse just needs access to the irq desc due to a massive design
    failure. Most arch implementations are easy to fix except for the
    x86 one which is an utter nightmare.

    affinity settings are easy to fix with the new chip functions

    show_interrupts() should be made generic code with an arch callback
    for the extra irq related statistics (NMI, direct vectors, etc.)

    The cpu hot unplug fixup functions which handle the move of
    interrupts from a hotplug CPU do not need access to irq_desc when
    the cpu unplug code calls into the genirq core code and let it
    migrate the interrupts before calling into the architecture
    specific cpu down function. That needs some more thought, but I
    think it's a solvable problem.

    Some private irq flow handlers in arch/ can be generalized and
    moved to the generic code.

    The remaining few cases where architecture or irq chip code
    fiddles with irq_desc->status are relatively easy to cleanup.

This is going to be a major surgery in some places so I need all the
help I can get, but parts of the cleanups can be done scripted. I hope
Julia can come up with a solution to go through the irq_chip functions
and convert most of them with spatch.

The transition phase is definitly going to be short and I'm not going
to keep the old chip functions around for years like we did with
__do_IRQ().

Comments ?

Thanks,

	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/

Powered by blists - more mailing lists