Date: Sun, 18 Oct 2009 09:05:42 -0500 (CDT) From: Mark Tinguely <tinguely@casselton.net> To: gballet@gmail.com, tinguely@casselton.net Cc: freebsd-arm@freebsd.org, stas@deglitch.com Subject: Re: Adding members to struct cpu_functions Message-ID: <200910181405.n9IE5gsi093570@casselton.net> In-Reply-To: <fd183dc60910180436k670648b0wca3900b8f47be6aa@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> =A0either, for the same reason. The compiler can not inline a call > >> =A0through a function pointer. > >> > >> =A0In which case, why not create a bunch of headers files with the > >> =A0pattern cpufunc_myarch.h, in which all functions would be declared > >> =A0inline? Something like: > >> > >> =A0static inline l2_l_entry(vm_addr_t pa, int prot, int cache); > >> =A0static inline l2_s_entry(vm_addr_t pa, int prot, int cache); > >> =A0... > >> =A0which 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. > > > > I'm not sure what you mean by that: would macros be ok, in your > opinion? I am a bit puzzled because I see a contradiction with the > previous sentence that requires the functions to be callable from the > assembly code. Obviously I am misinterpreting, so would you mind > clarifying, please? > > I think it is important to notice that even though cache management > relies a lot on assembly function, I haven't found any page table > management done in assembly past locore.S. I think using macros for > page table management functions can be done. For cache management, > however, I agree that having different pmap.c files is probably the > way to go. In both cases, I am still curious to see what Nathan will > come up with. You are correct, the page tables routines are pmap.c oriented. I extended clean up thought to all the cpu specific functions. There are cpu specific functions that are NOPs that we branch to and back again. I was just throwing out a global re-organization thought. > I took a more thorough look at pmap, and there is indeed lots of > machine-specific code, especially at the beginning. And when it comes > to cpufunc, it's all about #ifdefs. Since I'm still working on the > cleanup for the beagleboard, I will declare cpufuncs in an > armv6-specific file. Let's call it cpufunc_armv6.c. I am struggling > with another MMU problem at the moment, but I'll try to come up asap > with a patch for pmap.c. It will replace hardcoded values with > machine-defined macros, for reference. I think you are running that processor in v5 mode. There is still some individuals looking at a cache problem with recent code. I still believe, we need to add the PVF_REF flag when adding the new unmanaged (PVF_UNMAN) pv_entry, so pmap_fix_cache() will clean write back the cache and remove the tlb. That and the changes to remove dangling allocations. --Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200910181405.n9IE5gsi093570>