Re: [Xen-devel] struct irq_desc vs. struct irq_cfg

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.09.11 at 16:44, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel