From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 15:07:37 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E82A91065670; Mon, 12 Oct 2009 15:07:36 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 8EB828FC20; Mon, 12 Oct 2009 15:07:36 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id F182FC3BA8; Mon, 12 Oct 2009 17:01:55 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id jfVQxQ84+vdg; Mon, 12 Oct 2009 17:01:54 +0200 (CEST) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 0CEA5C3BA4; Mon, 12 Oct 2009 17:01:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Rafal Jaworowski In-Reply-To: <4AD32D76.3090401@freebsd.org> Date: Mon, 12 Oct 2009 17:07:33 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <4AD32D76.3090401@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1076) Cc: Guillaume Ballet , Mark Tinguely , freebsd-arm@freebsd.org, Stanislav Sedov Subject: Re: Adding members to struct cpu_functions X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 15:07:37 -0000 On 2009-10-12, at 15:21, Nathan Whitehorn wrote: >>>> I was wondering whether a separate pmap module for ARMv6-7 would >>>> not >>>> be the best approach. After all v6-7 should be considered an >>>> entirely >>>> new architecture variation, and we would avoid the very likely >>>> #ifdefs >>>> hell in case of a single pmap.c. >>>> >>>> >>> Yeah, I think that would be the best solution. We could >>> conditionally >>> select the right pmap.c file based on the target CPU selected (just >>> like we do for board variations for at91/marvell). >>> >>> >> >> pmap.c is a very large file that seems to change very often. I fear >> having several versions is going to be difficult to maintain. >> Granted, >> I haven't read the whole file line after line. Yet it seems to me its >> content can be abstracted to rely on arch-specific functions that >> would be found in cpufuncs instead of hardcoded macros. Is there >> something fundamentally wrong with enhancing struct cpufunc in order >> to let the portmeisters decide what the MMU and caching bits should >> look like? This is a blocking issue for me, since it looks like the >> omap has some problem with backward compatibility mode. Without >> fixing >> up the TLBs in my initarm function, it doesn't work. >> >> Speaking of #ifdef hell, why not breaking cpufuncs.c into several >> cpufuncs_.c? That would be a good way to start that >> reorganization Mark has been talking about in his email. >> > One thing that might be worth looking at while thinking about this > is how this is done on PowerPC. We have run-time selectable PMAP > modules using KOBJ to handle CPUs with different MMU designs, as > well as a platform module scheme, again using KOBJ, to pick the > appropriate PMAP for the board as well as determine the physical > memory layout and such things. One of the nice things about the > approach is that it is easy to subclass if you have a new, > marginally different, design, and it avoids #ifdef hell as well as > letting you build a GENERIC kernel with support for multiple MMU > designs and board types (the last less of a concern on ARM, though). What always concerned me was the performance cost this imposes, and it would be a really useful exercise to measure what is the actual impact of KOBJ-tized pmap we have in PowerPC; with an often-called interface like pmap it might occur the penalty is not that little.. Rafal