lkml.org 
[lkml]   [2008]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-08-15 10:53    [W:0.051 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site