From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Re: [patch] Add kexec_ops & function pointers Date: Tue, 12 Dec 2006 16:18:51 +0000 Message-ID: <1165940331.23643.72.camel@localhost.localdomain> References: <20061208161729.913385000@suse.de> <1165922822.23643.34.camel@localhost.localdomain> <457EA519.8040604@suse.de> <1165938346.23643.67.camel@localhost.localdomain> <457ED515.8020303@suse.de> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <457ED515.8020303@suse.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Gerd Hoffmann Cc: xen-devel@lists.xensource.com, Magnus Damm List-Id: xen-devel@lists.xenproject.org On Tue, 2006-12-12 at 17:13 +0100, Gerd Hoffmann wrote: > Ian Campbell wrote: > >>> Hiding the indirections through the function table in the header via > >>> defines or inline functions would make things a lot cleaner in my > >>> opinion and as a bonus avoid this addition to the sparse tree. > >> No. As machine_kexec() continues to exist (and is the default for > >> kexec_ops.kexec) you can't just turn that into a macro. You have to > >> either fix the two callers (as done by the patch) or rename the function > >> to something different in arch/*/kernel/machine_kexec.c in order to be > >> able to reuse the name for the macro. > > > > Yes you may need to rename some bits. I was thinking of a solution where > > you have foo_native, foo_xen0 and foo_xenU functions (or whatever) with > > an inline foo() which calls through the function table to the correct > > version. > > Sure. But renaming machine_kexec() to machine_kexec_native() or simliar > means touching a big bunch of files, namely > arch/{lots-of-directories-here}/kernel/machine_kexec.c. I'd prefer to > touch only one (kernel/sys.c) to keep the number of changes in the xen > tree small. You mean the versions for arch's other than i386 and x86_64? arch/{x86_64,i386}/kernel/machine_kexec.c are both in the sparse tree already. If you are adding the function table to all architectures then you are right, changing kernel/sys.c is much simpler. I thought the function table was an implementation detail on i386 and x86_64 only. Ian.