Date: Mon, 12 Oct 2009 16:29:17 -0500 (CDT) From: Mark Tinguely <tinguely@casselton.net> To: freebsd-arm@freebsd.org, gballet@gmail.com, nwhitehorn@freebsd.org, stas@deglitch.com, tinguely@casselton.net Subject: Re: Adding members to struct cpu_functions Message-ID: <200910122129.n9CLTHsp087996@casselton.net> In-Reply-To: <fd183dc60910121335l13403214yb1642102e4c36e08@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. I think they need to be regular function calls because assembly routines call the per-cpu functions. A few simple macros would save the branch to NOP functions. > 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? --Mark Tinguely
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200910122129.n9CLTHsp087996>