Date: Mon, 12 Oct 2009 17:07:33 +0200 From: Rafal Jaworowski <raj@semihalf.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: Guillaume Ballet <gballet@gmail.com>, Mark Tinguely <tinguely@casselton.net>, freebsd-arm@freebsd.org, Stanislav Sedov <stas@deglitch.com> Subject: Re: Adding members to struct cpu_functions Message-ID: <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> In-Reply-To: <4AD32D76.3090401@freebsd.org> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <fd183dc60910120529h5c741449rc8ad20b29fecd2ba@mail.gmail.com> <4AD32D76.3090401@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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_<myarch>.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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E>