Messages in this thread | | | Date | Fri, 15 Aug 2008 10:51:20 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 00/07] dyn_array/nr_irqs/sparse_irq support v10 - fix |
| |
* Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> On Fri, Aug 15, 2008 at 1:27 AM, Ingo Molnar <mingo@elte.hu> wrote: > > > > * Yinghai Lu <yhlu.kernel@gmail.com> wrote: > > > >> fix the 32bit with bigsmp > >> fix 64 bit with irq migration > >> ordering functions in io_apic_xx.c > >> > >> > >> to do: > >> merge io_apic_xx.c > > > > applied to tip/irq/sparseirq - thanks Yinghai, great work! > > > > What do you think about Eric's abstraction suggestion, that irq_desc's > > structure should be hidden from all but kernel/irq/* code. I think > > that's a sane suggestion. We do it in mm/slab.c too: no external code > > knows the structure of 'struct kmem_cache'. > > current arch code use irq_desc directly..., if need to irq_desc to > them, need to provide set_irq(..., ...)
that's ok - we can do include/linux/irq_desc.h that isnt generally included by drivers via interrupt.h. Then later on we can eliminate that include file altogether.
here's the current field usage histogram:
3 desc->action 3 desc->depth 9 desc->affinity 15 desc->chip 22 desc->status
desc->status: mostly IRQ_MOVE_PENDING related. irq-balancing code should be abstracted into kernel/irq/* perhaps?
desc->action / desc->depth / desc->action: i dont think those should be accessed by genirq arch irq code.
desc->chip: there's a get_irq_chip() method already. irq_chip is something that obviously is known to architecture code - it's the irq controller 'driver' that the architecture code provides.
Ingo
| |