From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Date: Wed, 24 Mar 2010 13:33:17 +0000 Subject: Re: [PATCH 01/10] irq: move some interrupt arch_* functions into Message-Id: <1269437597.10129.67623.camel@zakaz.uk.xensource.com> List-Id: References: <1269221770-9667-1-git-send-email-yinghai@kernel.org> <1269221770-9667-2-git-send-email-yinghai@kernel.org> <1269222962.3534.12.camel@concordia> <4BA6E4D1.6080704@kernel.org> <20100323071006.GJ13417@linux-sh.org> In-Reply-To: <20100323071006.GJ13417@linux-sh.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Paul Mundt Cc: "lguest@ozlabs.org" , "x86@kernel.org" , Andrew Morton , "linux-sh@vger.kernel.org" , Rusty Russell , Jeremy Fitzhardinge , Jesse Barnes , "linux-kernel@vger.kernel.org" , "linuxppc-dev@ozlabs.org" , Ingo Molnar , Paul Mackerras , "Eric W. Biederman" , "H. Peter Anvin" , Ingo Molnar , Yinghai Lu , Thomas Gleixner On Tue, 2010-03-23 at 07:10 +0000, Paul Mundt wrote: > The function pointer thing itself is also a bit unorthodox to say the > least. You're introducing and passing around an opaque type just so you > can get to a 'return 0' in the xen case as far as I can tell, The ultimate aim is to have Xen use the chip data to store the event channel information relating to each IRQ instead of keeping it in a static NR_IRQs array, the new function only returns 0 as a placeholder until this can be put in place (which depends on these changes), it could as well have been left out for the time being (e.g. passing NULL function pointer in the Xen case or whatever). > so you > could also just make arch_init_chip_data() a weak symbol and clobber it > in the xen case, no? A single kernel is able to boot native or Xen so a weak symbol doesn't really work, having the function pointer at the arch level is one similar option, I've replied to Thomas' similar suggestion. Ian. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756077Ab0CXNdY (ORCPT ); Wed, 24 Mar 2010 09:33:24 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:20346 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755085Ab0CXNdW (ORCPT ); Wed, 24 Mar 2010 09:33:22 -0400 X-IronPort-AV: E=Sophos;i="4.51,301,1267419600"; d="scan'208";a="89407457" Subject: Re: [PATCH 01/10] irq: move some interrupt arch_* functions into struct irq_chip. From: Ian Campbell To: Paul Mundt CC: Yinghai Lu , "michael@ellerman.id.au" , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Andrew Morton , "Eric W. Biederman" , Jesse Barnes , "lguest@ozlabs.org" , Jeremy Fitzhardinge , Rusty Russell , "linux-sh@vger.kernel.org" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "linuxppc-dev@ozlabs.org" , Ingo Molnar , Paul Mackerras In-Reply-To: <20100323071006.GJ13417@linux-sh.org> References: <1269221770-9667-1-git-send-email-yinghai@kernel.org> <1269221770-9667-2-git-send-email-yinghai@kernel.org> <1269222962.3534.12.camel@concordia> <4BA6E4D1.6080704@kernel.org> <20100323071006.GJ13417@linux-sh.org> Content-Type: text/plain; charset="UTF-8" Organization: Citrix Systems, Inc. Date: Wed, 24 Mar 2010 13:33:17 +0000 Message-ID: <1269437597.10129.67623.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 X-Mailer: Evolution 2.28.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2010-03-23 at 07:10 +0000, Paul Mundt wrote: > The function pointer thing itself is also a bit unorthodox to say the > least. You're introducing and passing around an opaque type just so you > can get to a 'return 0' in the xen case as far as I can tell, The ultimate aim is to have Xen use the chip data to store the event channel information relating to each IRQ instead of keeping it in a static NR_IRQs array, the new function only returns 0 as a placeholder until this can be put in place (which depends on these changes), it could as well have been left out for the time being (e.g. passing NULL function pointer in the Xen case or whatever). > so you > could also just make arch_init_chip_data() a weak symbol and clobber it > in the xen case, no? A single kernel is able to boot native or Xen so a weak symbol doesn't really work, having the function pointer at the arch level is one similar option, I've replied to Thomas' similar suggestion. Ian. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [PATCH 01/10] irq: move some interrupt arch_* functions into struct irq_chip. From: Ian Campbell To: Paul Mundt In-Reply-To: <20100323071006.GJ13417@linux-sh.org> References: <1269221770-9667-1-git-send-email-yinghai@kernel.org> <1269221770-9667-2-git-send-email-yinghai@kernel.org> <1269222962.3534.12.camel@concordia> <4BA6E4D1.6080704@kernel.org> <20100323071006.GJ13417@linux-sh.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 24 Mar 2010 13:33:17 +0000 Message-ID: <1269437597.10129.67623.camel@zakaz.uk.xensource.com> MIME-Version: 1.0 Cc: "lguest@ozlabs.org" , "x86@kernel.org" , Andrew Morton , "linux-sh@vger.kernel.org" , Rusty Russell , Jeremy Fitzhardinge , Jesse Barnes , "linux-kernel@vger.kernel.org" , "linuxppc-dev@ozlabs.org" , Ingo Molnar , Paul Mackerras , "Eric W. Biederman" , "H. Peter Anvin" , Ingo Molnar , Yinghai Lu , Thomas Gleixner List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 2010-03-23 at 07:10 +0000, Paul Mundt wrote: > The function pointer thing itself is also a bit unorthodox to say the > least. You're introducing and passing around an opaque type just so you > can get to a 'return 0' in the xen case as far as I can tell, The ultimate aim is to have Xen use the chip data to store the event channel information relating to each IRQ instead of keeping it in a static NR_IRQs array, the new function only returns 0 as a placeholder until this can be put in place (which depends on these changes), it could as well have been left out for the time being (e.g. passing NULL function pointer in the Xen case or whatever). > so you > could also just make arch_init_chip_data() a weak symbol and clobber it > in the xen case, no? A single kernel is able to boot native or Xen so a weak symbol doesn't really work, having the function pointer at the arch level is one similar option, I've replied to Thomas' similar suggestion. Ian.