* Yinghai Lu <yhlu.kernel@gmail.com> wrote:

quoted text
> 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
--
unsubscribe notice
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/