On 29 May 2002, Justin Carlson wrote: > Here's a patch against cvs that does the rename. Unless anyone has > objections, Ralf, could you apply this? That looks fine to me. I'd keep the leading double underscore, though -- it acts as a warning sign the function is internal and low-level and thus it should not be used without an appropriate justification. > While doing this, I've noticed that the whole mips tree is horribly > inconsistent in terms of the cache flushing syscalls (sys_cacheflush and > sys_sysmips->CACHE_FLUSH). Ugh, it's not the only place of inconsistency... > Here's what the different ports appear to flush given one of these > syscall: > > andes: l1 and l2 > lexra: l1 icache > mips32: l1 icache/dcache > r3k: l1 icache > r4k: l1 icache/dcache > r5432: l1 icache/dcache > r5900: l1 icache/dcache > rm7k: l1 icache/dcache > sb1: l1 icache/dcache > sr7100: l1 and l2 > tx39: l1 icache > tx49: li icache/dcache > > Some of these are blatantly wrong with respect to the cacheflush > syscall; it defines flags for flushing the icache, dcache, or both. In > the latter two cases, the lexra, r3k, and tx39 are not doing what was > requested. I doubt this matters for any significant userspace app, but > it would be nice to at least be consistent. Well, at least r3k uses WT for dcache, so it really doesn't matter unless what you want to achieve is to hit performance. I suspect this is also the case for the others that ignore dcache flushes. The L1 vs L2 issue should be investigated where applicable. This reminds me to check ld.so (and libdl) for missing sys_cacheflush() invocations as well... > As for the sysmips system call, I've not been able to dig up the > semantics. (Actually, I don't really see why we have both ways of > flushing the cache at all...some historical cruft?). Anyone have a > helpful pointer to docs on the subject? It's compatibility crap, like the whole sysmips() stuff, I am afraid. Use sys_cacheflush() normally. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
