From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: struct irq_desc vs. struct irq_cfg Date: Tue, 6 Sep 2011 15:44:05 +0100 Message-ID: <4E6631B5.8030308@citrix.com> References: <4E664B9D0200007800054D6D@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4E664B9D0200007800054D6D@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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