struct irq_desc vs. struct irq_cfg

struct irq_desc vs. struct irq_cfg

[Jan Beulich]

Originally, iirc, struct irq_desc's chip_data pointer was intended to be set to
something specific to the struct hw_interrupt_type instance that's being
put into its handler pointer. Currently, however, struct irq_cfg is being
used universally (and carries data that is also intended to be available) for
all interrupt types. Wouldn't it make sense to move global data back into
struct irq_desc, or should we rather introduce a second pointer (e.g.
handler_data) in struct irq_desc to allow handler specific context to be
stored?

Thanks, Jan

Re: struct irq_desc vs. struct irq_cfg

[Andrew Cooper]

On 06/09/11 15:34, Jan Beulich wrote:
> Originally, iirc, struct irq_desc's chip_data pointer was intended to be set to
> something specific to the struct hw_interrupt_type instance that's being
> put into its handler pointer. Currently, however, struct irq_cfg is being
> used universally (and carries data that is also intended to be available) for
> all interrupt types. Wouldn't it make sense to move global data back into
> struct irq_desc, or should we rather introduce a second pointer (e.g.
> handler_data) in struct irq_desc to allow handler specific context to be
> stored?

I believe I asked this question in my long email about the direction of
irq cleanup (and if not, I certainly intended to)

As the inequality irq_desc[irq].chip-data == irq_cfg[irq] is maintained
at all times, merging the two would make sense, as well as removing many
needless indirections, and nr_irqs pointers.

Therefore, I vote to merge the two.

What were you considering to contain in the handler specific context?

> Thanks, Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

Re: struct irq_desc vs. struct irq_cfg

[Jan Beulich]

>>> On 06.09.11 at 16:44, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 06/09/11 15:34, Jan Beulich wrote:
>> Originally, iirc, struct irq_desc's chip_data pointer was intended to be set 
> to
>> something specific to the struct hw_interrupt_type instance that's being
>> put into its handler pointer. Currently, however, struct irq_cfg is being
>> used universally (and carries data that is also intended to be available) 
> for
>> all interrupt types. Wouldn't it make sense to move global data back into
>> struct irq_desc, or should we rather introduce a second pointer (e.g.
>> handler_data) in struct irq_desc to allow handler specific context to be
>> stored?
> 
> I believe I asked this question in my long email about the direction of
> irq cleanup (and if not, I certainly intended to)
> 
> As the inequality irq_desc[irq].chip-data == irq_cfg[irq] is maintained
> at all times, merging the two would make sense, as well as removing many
> needless indirections, and nr_irqs pointers.
> 
> Therefore, I vote to merge the two.
> 
> What were you considering to contain in the handler specific context?

Actually I meanwhile think I can get away without - the places it's
desirable are the various MSI sub-types (HPET, IOMMU), but there I
can assume that only a single action instance exists for each IRQ,
and hence I can equally well use desc->action->dev_id (I was really
after being able to use what is already being put there from the
various struct hw_interrupt_type actors, while perhaps also converting
all of those to take a struct irq_desc * instead of the numerical IRQ as
first argument).

Jan