Date: Mon, 12 Oct 2009 22:35:26 +0200 From: Guillaume Ballet <gballet@gmail.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org>, Mark Tinguely <tinguely@casselton.net>, freebsd-arm@freebsd.org, Stanislav Sedov <stas@deglitch.com> Subject: Re: Adding members to struct cpu_functions Message-ID: <fd183dc60910121335l13403214yb1642102e4c36e08@mail.gmail.com> In-Reply-To: <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> 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> <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 12, 2009 at 5:07 PM, Rafal Jaworowski <raj@semihalf.com> wrote: > > 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 #ifdef= s >>>>> hell in case of a single pmap.c. >>>>> >>>>> >>>> Yeah, I think that would be the best solution. =A0We could conditional= ly >>>> 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 ho= w >> 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 n= ew, >> marginally different, design, and it avoids #ifdef hell as well as letti= ng >> you build a GENERIC kernel with support for multiple MMU designs and boa= rd >> types (the last less of a concern on ARM, though). > > What always concerned me was the performance cost this imposes, and it wo= uld > 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 p= map > it might occur the penalty is not that little.. > > Rafal > > Good point. Using KOBJs this way is really cool, but the overhead is going to be a concern if it is used by an application that allocates memory very often. This is not the case of most embedded appliances I worked with, still one should not assume anything about the userland at kernel level. As a result, extending the struct cpu_functions is not a good thing either, for the same reason. The compiler can not inline a call through a function pointer. In which case, why not create a bunch of headers files with the pattern cpufunc_myarch.h, in which all functions would be declared inline? Something like: static inline l2_l_entry(vm_addr_t pa, int prot, int cache); static inline l2_s_entry(vm_addr_t pa, int prot, int cache); ... which would then be included by pmap.c and friends. One problem is that such a change affects all platforms at the same time, and therefore requires all portmeisters to implement the functions that are needed. That should not be too difficult, though, because so far it was the same macros that were used by all platforms. Another problem is that it requires some build script magic to make sure the correct header is included depending on the arch. I wonder if this is easy? Guillaume
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fd183dc60910121335l13403214yb1642102e4c36e08>