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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel